From david.garnier at trusted-logic.fr  Thu Nov  6 12:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu Nov  6 11:00:27 2003
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry@12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry@12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry@12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner@12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj@www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry@12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry@12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry@12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry@12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 
From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu Nov  6 15:18:35 2003
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson@yahoo.com


From dmarkman at mac.com  Thu Nov  6 11:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu Nov  6 16:29:56 2003
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson@yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman

From dmarkman at mac.com  Thu Nov  6 12:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu Nov  6 17:43:36 2003
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson@yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman

From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu Nov  6 18:06:59 2003
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman@mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx@linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>

From dmarkman at mac.com  Thu Nov  6 14:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu Nov  6 19:16:44 2003
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman@mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx@linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx@linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman

From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu Nov  6 20:00:58 2003
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>

From dmarkman at mac.com  Thu Nov  6 16:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu Nov  6 21:04:24 2003
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman

From david.garnier at trusted-logic.fr  Fri Nov  7 16:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri Nov  7 14:59:49 2003
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri Nov  7 21:47:29 2003
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
/*
* Test.class is just that.. a Test
*/


import java.io.*;
import java.util.*;
import gnu.io.*;

public class TestCrash implements SerialPortEventListener,
                                  CommPortOwnershipListener {

InputStream inputStream;
OutputStream outputStream;
SerialPort serialPort;
Thread readThread;
boolean debug = true;
boolean doDebugMessages = debug;
public static final char  FUNCTION_RESET       = 0xC1;

	public static void main(String[] args) {
		CommPortIdentifier portId;
		Enumeration portList;
		portList = CommPortIdentifier.getPortIdentifiers();
		while (portList.hasMoreElements()) {
			portId = (CommPortIdentifier) portList.nextElement();
			if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) {
                if ( portId.isCurrentlyOwned() ) {
                    System.out.println(portId.getName() + " with isCurrentlyOwned: true");
                } else {
                    System.out.println(portId.getName() + " with isCurrentlyOwned: false");
                    new TestCrash(portId);
                }
				//System.out.println(portId.getName() + " with owner: " + portId.getCurrentOwner());
			}
		}
		if (args.length < 1) {
			System.out.print("Test.class /dev/ports/serialx\n");
			System.exit(-1);
		}
		//System.out.println(System.getProperty("java.library.path"));
		//System.out.println("opening the Port: " + args[0]);		
		//Test reader = new Test(args[0]);
	}

	public TestCrash(CommPortIdentifier portId) {
        try {
            portId.addPortOwnershipListener(this);
            System.out.println(portId.getName() + " just set this as owner.");

            // get the port object
            serialPort = (SerialPort)portId.open("Test panther crash", 2000);
    
            // flow i/o
            serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE);
            outputStream  = serialPort.getOutputStream();
            inputStream   = serialPort.getInputStream();
    
            // settings
            serialPort.disableReceiveFraming();
            serialPort.disableReceiveThreshold();
            serialPort.disableReceiveTimeout();
    
            // set baud rate
            serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
                                        SerialPort.STOPBITS_1, 
                                        SerialPort.PARITY_NONE);
    
            // provide power to the device
            serialPort.setDTR(true);
            serialPort.setRTS(true);
    
            // setup the listener
            serialPort.addEventListener(this);
            //serialPort.notifyOnDataAvailable(true);
            serialPort.notifyOnOutputEmpty(true);
            serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
                                           SerialPort.STOPBITS_1, 
                                           SerialPort.PARITY_NONE);
      
            // send a break to reset DS2480
            serialPort.sendBreak(5);

            // send the timing byte
            flushCom();
            writeCom(FUNCTION_RESET);
            flushCom();

        } catch(Exception e) {
            System.err.println("Exception creating and initing serial port: " + e.getMessage());
        } finally {
            if (serialPort != null)
               serialPort.close();
    
            // failed to get the port, clean up
            portId.removePortOwnershipListener(this);
            serialPort = null;
        }
	}
   //-------------------------------------------------------------------------
   /** Write a single character to the com port
    *
    *  @param  writeVal  the data byte to write.
    *
    *  @return 'true' if byte written without error.
    */
   private boolean writeCom(char writeVal)
   {
      // provided debug on standard out
      if (doDebugMessages)
         System.out.print("W(" + Integer.toHexString(writeVal) + ")");

      try
      {
         outputStream.write((int)writeVal);
         outputStream.flush();
         return true;
      }
      catch(Exception E)
      {
         // provided debug on standard out
         System.out.println("EXCEPTION: USerialAdapter-writeCom(): " + E);
      }

      return false;
   }
    /** Flush the input and output buffer of any data
     */
    private void flushCom()
    {
      // provided debug on standard out
      if (debug)
         System.out.println("DEBUG: USerialAdapter-flush");

      try
      {
         // flush the output
         outputStream.flush();

         // flush the input buffer
         if (inputStream.available() > 0)
         {
            byte[] dummy = new byte[inputStream.available()];
            inputStream.read(dummy);
         }
      }
      catch(Exception E)
      {
         // provided debug on standard out
         System.out.println("EXCEPTION: USerialAdapter-flush: " + E);
      }
    }

	public TestCrash(String PortName) {
		RXTXCommDriver TxPort = new RXTXCommDriver();
		System.out.print("open Ports\n");		
		serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL);
		System.out.println("Get Streams from serialPort: " + serialPort);		
		try {
			inputStream = serialPort.getInputStream();
			outputStream = serialPort.getOutputStream();
		} catch (IOException e) {
			e.printStackTrace();
		}
		try {
			serialPort.addEventListener(this);
		} catch (TooManyListenersException e) {
			e.printStackTrace();
		}
		try {
			System.out.println("Baud is " + serialPort.getBaudRate());	
			System.out.println("Bits is " + serialPort.getDataBits());	
			System.out.println("Stop is " + serialPort.getStopBits());	
			System.out.println("Par is " + serialPort.getParity());	
			System.out.print("Set Params\n");		
			serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE);
			System.out.println("Baud is " + serialPort.getBaudRate());	
			System.out.println("Bits is " + serialPort.getDataBits());	
			System.out.println("Stop is " + serialPort.getStopBits());	
			System.out.println("Par is " + serialPort.getParity());	
			System.out.print("Set Params\n");		
			serialPort.setSerialPortParams(9600, SerialPort.DATABITS_7, SerialPort.STOPBITS_2, SerialPort.PARITY_ODD);
			System.out.println("Baud is " + serialPort.getBaudRate());	
			System.out.println("Bits is " + serialPort.getDataBits());	
			System.out.println("Stop is " + serialPort.getStopBits());	
			System.out.println("Par is " + serialPort.getParity());	
		} catch (UnsupportedCommOperationException e) {
			e.printStackTrace();
		}
		System.out.print("Sending 0x01\n");		
		try {
			outputStream.write((byte)0x01);
			System.out.print("0x01 Sent\n");		
		} catch (IOException e) {
			e.printStackTrace();
		}
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType()) {
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
                                System.out.print("Data Available\n");
                                break;
                }
        }

   /** Oneship change event, required to be an CommPortOwnershipListener
    *
    *  @param  type   ownership change type
    */
   public void ownershipChange(int type)
   {
      switch(type)
      {
         case PORT_OWNED:
            // provided debug on standard out
            if (debug)
               System.out.println("DEBUG: USerialAdapter-Ownership Change -  PORT_OWNED" +
                                  " by thread " + Thread.currentThread());
            break;
         case PORT_UNOWNED:
            // provided debug on standard out
            if (debug)
                System.out.println("DEBUG: USerialAdapter-Ownership Change -  PORT_UNOWNED" + 
                                   " by thread " + Thread.currentThread());
            break;
         case PORT_OWNERSHIP_REQUESTED:
            // provided debug on standard out
            if (debug)
               System.out.println("DEBUG: USerialAdapter-Ownership Change -  PORT_OWNERSHIP_REQUESTED" + 
                                  " by thread " + Thread.currentThread());
            break;
      }// switch

   }
}

-------------- next part --------------


From p_narayanamurthy at yahoo.com  Fri Nov  7 22:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Sat Nov  8 06:31:03 2003
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
From taj at linuxgrrls.org  Sun Nov  9 17:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun Nov  9 17:07:08 2003
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.


From edpersson at yahoo.com  Wed Nov  5 12:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Sun Nov  9 17:07:19 2003
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson@yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
From mba at embedded-zone.com  Thu Nov  6 07:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Sun Nov  9 17:07:21 2003
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.linuxgrrls.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment.htm
From ballagas at cs.rwth-aachen.de  Sun Nov  9 19:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun Nov  9 18:03:13 2003
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----


From taj at linuxgrrls.org  Mon Nov 10 06:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon Nov 10 06:33:33 2003
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.
From taj at linuxgrrls.org  Mon Nov 10 19:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon Nov 10 19:00:59 2003
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.
From taj at linuxgrrls.org  Mon Nov 10 19:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon Nov 10 19:05:03 2003
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.
From taj at linuxgrrls.org  Mon Nov 10 20:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon Nov 10 20:11:10 2003
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry@12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry@12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry@12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner@12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.
From john_db_adams at yahoo.com  Mon Nov 10 12:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon Nov 10 20:23:22 2003
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
From taj at linuxgrrls.org  Mon Nov 10 21:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon Nov 10 21:32:36 2003
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.

From taj at linuxgrrls.org  Mon Nov 10 21:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon Nov 10 21:54:06 2003
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}
From taj at linuxgrrls.org  Mon Nov 10 23:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon Nov 10 23:19:04 2003
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...
From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Tue Nov 11 02:05:48 2003
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>

From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Tue Nov 11 02:49:12 2003
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik

From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 13:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue Nov 11 15:18:57 2003
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels
From john_db_adams at yahoo.com  Tue Nov 11 07:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue Nov 11 15:31:50 2003
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels@weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 10:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue Nov 11 18:01:59 2003
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels
From taj at linuxgrrls.org  Wed Nov 12 00:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed Nov 12 00:05:08 2003
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels@weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx@linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
From webmaster at geschwinde.net  Wed Nov 12 15:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed Nov 12 14:11:35 2003
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde



From taj at linuxgrrls.org  Wed Nov 12 14:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed Nov 12 14:53:49 2003
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
From webmaster at geschwinde.net  Wed Nov 12 16:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed Nov 12 15:06:13 2003
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>


From webmaster at geschwinde.net  Wed Nov 12 17:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed Nov 12 16:03:50 2003
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>


From taj at linuxgrrls.org  Wed Nov 12 18:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed Nov 12 18:47:57 2003
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.
From c.marschalek at schrack-seconet.com  Thu Nov 13 12:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu Nov 13 11:39:54 2003
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM

From taj at www.linux.org.uk  Thu Nov 13 16:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu Nov 13 15:51:51 2003
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root@arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");


From taj at linuxgrrls.org  Thu Nov 13 16:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu Nov 13 16:00:35 2003
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."
From webmaster at geschwinde.net  Thu Nov 13 18:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu Nov 13 17:01:31 2003
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>


From taj at linuxgrrls.org  Thu Nov 13 17:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu Nov 13 17:19:18 2003
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
From c.marschalek at schrack-seconet.com  Fri Nov 14 07:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Nov 14 06:15:14 2003
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM

From c.marschalek at schrack-seconet.com  Fri Nov 14 07:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Nov 14 06:17:59 2003
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM

From taj at linuxgrrls.org  Fri Nov 14 07:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Nov 14 07:00:53 2003
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.



From c.marschalek at schrack-seconet.com  Fri Nov 14 08:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Nov 14 07:11:50 2003
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM

From taj at linuxgrrls.org  Fri Nov 14 07:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Nov 14 07:12:17 2003
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.

From taj at linuxgrrls.org  Fri Nov 14 07:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Nov 14 07:22:06 2003
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.
From c.marschalek at schrack-seconet.com  Fri Nov 14 08:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Nov 14 07:27:31 2003
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.

From taj at linuxgrrls.org  Fri Nov 14 07:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Nov 14 07:32:35 2003
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.

From halbleib at rechnerbetriebsgruppe.de  Fri Nov 14 03:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri Nov 14 08:07:30 2003
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek@schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


From c.marschalek at schrack-seconet.com  Fri Nov 14 09:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Nov 14 08:08:41 2003
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(

From taj at linuxgrrls.org  Fri Nov 14 08:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Nov 14 08:17:46 2003
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.
From c.marschalek at schrack-seconet.com  Fri Nov 14 09:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Nov 14 08:22:46 2003
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?

From taj at linuxgrrls.org  Fri Nov 14 08:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Nov 14 08:26:46 2003
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.
From c.marschalek at schrack-seconet.com  Fri Nov 14 09:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Nov 14 08:29:28 2003
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)

From taj at linuxgrrls.org  Fri Nov 14 08:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Nov 14 08:37:46 2003
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.
From c.marschalek at schrack-seconet.com  Fri Nov 14 09:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Nov 14 08:46:49 2003
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)

From c.marschalek at schrack-seconet.com  Fri Nov 14 10:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Nov 14 09:03:40 2003
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)

From taj at linuxgrrls.org  Fri Nov 14 09:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Nov 14 09:10:50 2003
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'
From c.marschalek at schrack-seconet.com  Fri Nov 14 13:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Nov 14 12:19:23 2003
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?

From vinu at ntcb.com  Fri Nov 14 12:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri Nov 14 18:04:13 2003
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu@ntcb.com

From taj at linuxgrrls.org  Fri Nov 14 18:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Nov 14 18:21:37 2003
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.
From taj at linuxgrrls.org  Fri Nov 21 20:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Nov 21 20:56:07 2003
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/

From patrick at tendim.cjb.net  Tue Nov 25 01:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue Nov 25 06:25:15 2003
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick

From dmarkman at mac.com  Wed Nov 26 00:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed Nov 26 05:05:21 2003
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman

From taj at linuxgrrls.org  Fri Nov 28 04:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Nov 28 04:22:54 2003
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.
From patrick at tendim.cjb.net  Fri Nov 28 11:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri Nov 28 16:03:20 2003
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>

From taj at www.linux.org.uk  Fri Nov 28 21:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri Nov 28 21:05:17 2003
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj@www.linux.org.uk

From david.garnier at trusted-logic.fr  Thu Nov  6 11:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri Jun  3 17:45:54 2005
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry@12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry@12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry@12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner@12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj@www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry@12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry@12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry@12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry@12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 
From edpersson at qwest.net  Thu Nov  6 15:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri Jun  3 17:45:55 2005
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson@yahoo.com



From dmarkman at mac.com  Thu Nov  6 16:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Fri Jun  3 17:45:55 2005
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson@yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman


From dmarkman at mac.com  Thu Nov  6 17:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Fri Jun  3 17:45:55 2005
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson@yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman


From edpersson at qwest.net  Thu Nov  6 18:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri Jun  3 17:45:55 2005
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman@mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx@linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>


From dmarkman at mac.com  Thu Nov  6 19:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Fri Jun  3 17:45:56 2005
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman@mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx@linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx@linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman


From edpersson at qwest.net  Thu Nov  6 20:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri Jun  3 17:45:56 2005
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>


From dmarkman at mac.com  Thu Nov  6 21:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Fri Jun  3 17:45:56 2005
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman


From david.garnier at trusted-logic.fr  Fri Nov  7 15:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri Jun  3 17:45:56 2005
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
From edpersson at qwest.net  Fri Nov  7 21:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri Jun  3 17:45:56 2005
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
/*
* Test.class is just that.. a Test
*/


import java.io.*;
import java.util.*;
import gnu.io.*;

public class TestCrash implements SerialPortEventListener,
                                  CommPortOwnershipListener {

InputStream inputStream;
OutputStream outputStream;
SerialPort serialPort;
Thread readThread;
boolean debug = true;
boolean doDebugMessages = debug;
public static final char  FUNCTION_RESET       = 0xC1;

	public static void main(String[] args) {
		CommPortIdentifier portId;
		Enumeration portList;
		portList = CommPortIdentifier.getPortIdentifiers();
		while (portList.hasMoreElements()) {
			portId = (CommPortIdentifier) portList.nextElement();
			if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) {
                if ( portId.isCurrentlyOwned() ) {
                    System.out.println(portId.getName() + " with isCurrentlyOwned: true");
                } else {
                    System.out.println(portId.getName() + " with isCurrentlyOwned: false");
                    new TestCrash(portId);
                }
				//System.out.println(portId.getName() + " with owner: " + portId.getCurrentOwner());
			}
		}
		if (args.length < 1) {
			System.out.print("Test.class /dev/ports/serialx\n");
			System.exit(-1);
		}
		//System.out.println(System.getProperty("java.library.path"));
		//System.out.println("opening the Port: " + args[0]);		
		//Test reader = new Test(args[0]);
	}

	public TestCrash(CommPortIdentifier portId) {
        try {
            portId.addPortOwnershipListener(this);
            System.out.println(portId.getName() + " just set this as owner.");

            // get the port object
            serialPort = (SerialPort)portId.open("Test panther crash", 2000);
    
            // flow i/o
            serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE);
            outputStream  = serialPort.getOutputStream();
            inputStream   = serialPort.getInputStream();
    
            // settings
            serialPort.disableReceiveFraming();
            serialPort.disableReceiveThreshold();
            serialPort.disableReceiveTimeout();
    
            // set baud rate
            serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
                                        SerialPort.STOPBITS_1, 
                                        SerialPort.PARITY_NONE);
    
            // provide power to the device
            serialPort.setDTR(true);
            serialPort.setRTS(true);
    
            // setup the listener
            serialPort.addEventListener(this);
            //serialPort.notifyOnDataAvailable(true);
            serialPort.notifyOnOutputEmpty(true);
            serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
                                           SerialPort.STOPBITS_1, 
                                           SerialPort.PARITY_NONE);
      
            // send a break to reset DS2480
            serialPort.sendBreak(5);

            // send the timing byte
            flushCom();
            writeCom(FUNCTION_RESET);
            flushCom();

        } catch(Exception e) {
            System.err.println("Exception creating and initing serial port: " + e.getMessage());
        } finally {
            if (serialPort != null)
               serialPort.close();
    
            // failed to get the port, clean up
            portId.removePortOwnershipListener(this);
            serialPort = null;
        }
	}
   //-------------------------------------------------------------------------
   /** Write a single character to the com port
    *
    *  @param  writeVal  the data byte to write.
    *
    *  @return 'true' if byte written without error.
    */
   private boolean writeCom(char writeVal)
   {
      // provided debug on standard out
      if (doDebugMessages)
         System.out.print("W(" + Integer.toHexString(writeVal) + ")");

      try
      {
         outputStream.write((int)writeVal);
         outputStream.flush();
         return true;
      }
      catch(Exception E)
      {
         // provided debug on standard out
         System.out.println("EXCEPTION: USerialAdapter-writeCom(): " + E);
      }

      return false;
   }
    /** Flush the input and output buffer of any data
     */
    private void flushCom()
    {
      // provided debug on standard out
      if (debug)
         System.out.println("DEBUG: USerialAdapter-flush");

      try
      {
         // flush the output
         outputStream.flush();

         // flush the input buffer
         if (inputStream.available() > 0)
         {
            byte[] dummy = new byte[inputStream.available()];
            inputStream.read(dummy);
         }
      }
      catch(Exception E)
      {
         // provided debug on standard out
         System.out.println("EXCEPTION: USerialAdapter-flush: " + E);
      }
    }

	public TestCrash(String PortName) {
		RXTXCommDriver TxPort = new RXTXCommDriver();
		System.out.print("open Ports\n");		
		serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL);
		System.out.println("Get Streams from serialPort: " + serialPort);		
		try {
			inputStream = serialPort.getInputStream();
			outputStream = serialPort.getOutputStream();
		} catch (IOException e) {
			e.printStackTrace();
		}
		try {
			serialPort.addEventListener(this);
		} catch (TooManyListenersException e) {
			e.printStackTrace();
		}
		try {
			System.out.println("Baud is " + serialPort.getBaudRate());	
			System.out.println("Bits is " + serialPort.getDataBits());	
			System.out.println("Stop is " + serialPort.getStopBits());	
			System.out.println("Par is " + serialPort.getParity());	
			System.out.print("Set Params\n");		
			serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE);
			System.out.println("Baud is " + serialPort.getBaudRate());	
			System.out.println("Bits is " + serialPort.getDataBits());	
			System.out.println("Stop is " + serialPort.getStopBits());	
			System.out.println("Par is " + serialPort.getParity());	
			System.out.print("Set Params\n");		
			serialPort.setSerialPortParams(9600, SerialPort.DATABITS_7, SerialPort.STOPBITS_2, SerialPort.PARITY_ODD);
			System.out.println("Baud is " + serialPort.getBaudRate());	
			System.out.println("Bits is " + serialPort.getDataBits());	
			System.out.println("Stop is " + serialPort.getStopBits());	
			System.out.println("Par is " + serialPort.getParity());	
		} catch (UnsupportedCommOperationException e) {
			e.printStackTrace();
		}
		System.out.print("Sending 0x01\n");		
		try {
			outputStream.write((byte)0x01);
			System.out.print("0x01 Sent\n");		
		} catch (IOException e) {
			e.printStackTrace();
		}
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType()) {
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
                                System.out.print("Data Available\n");
                                break;
                }
        }

   /** Oneship change event, required to be an CommPortOwnershipListener
    *
    *  @param  type   ownership change type
    */
   public void ownershipChange(int type)
   {
      switch(type)
      {
         case PORT_OWNED:
            // provided debug on standard out
            if (debug)
               System.out.println("DEBUG: USerialAdapter-Ownership Change -  PORT_OWNED" +
                                  " by thread " + Thread.currentThread());
            break;
         case PORT_UNOWNED:
            // provided debug on standard out
            if (debug)
                System.out.println("DEBUG: USerialAdapter-Ownership Change -  PORT_UNOWNED" + 
                                   " by thread " + Thread.currentThread());
            break;
         case PORT_OWNERSHIP_REQUESTED:
            // provided debug on standard out
            if (debug)
               System.out.println("DEBUG: USerialAdapter-Ownership Change -  PORT_OWNERSHIP_REQUESTED" + 
                                  " by thread " + Thread.currentThread());
            break;
      }// switch

   }
}

-------------- next part --------------


From p_narayanamurthy at yahoo.com  Sat Nov  8 06:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri Jun  3 17:45:56 2005
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

From taj at linuxgrrls.org  Sun Nov  9 17:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:45:56 2005
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.



From edpersson at yahoo.com  Wed Nov  5 20:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Fri Jun  3 17:45:57 2005
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson@yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

From mba at embedded-zone.com  Thu Nov  6 12:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Fri Jun  3 17:45:57 2005
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pixie.strangenoises.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0002.htm
From ballagas at cs.rwth-aachen.de  Sun Nov  9 18:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Fri Jun  3 17:45:57 2005
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----



From taj at linuxgrrls.org  Mon Nov 10 06:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:45:57 2005
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.

From taj at linuxgrrls.org  Mon Nov 10 19:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:45:57 2005
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.

From taj at linuxgrrls.org  Mon Nov 10 19:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:45:57 2005
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.

From taj at linuxgrrls.org  Mon Nov 10 20:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:45:57 2005
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry@12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry@12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry@12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner@12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.

From john_db_adams at yahoo.com  Mon Nov 10 20:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Fri Jun  3 17:45:57 2005
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

From taj at linuxgrrls.org  Mon Nov 10 21:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:45:57 2005
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.


From taj at linuxgrrls.org  Mon Nov 10 21:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:45:57 2005
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}
From taj at linuxgrrls.org  Mon Nov 10 23:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:45:58 2005
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...

From edpersson at qwest.net  Tue Nov 11 02:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri Jun  3 17:45:58 2005
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>


From edpersson at qwest.net  Tue Nov 11 02:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri Jun  3 17:45:58 2005
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik


From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 21:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Fri Jun  3 17:45:58 2005
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels

From john_db_adams at yahoo.com  Tue Nov 11 15:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Fri Jun  3 17:45:58 2005
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels@weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 18:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Fri Jun  3 17:45:58 2005
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels

From taj at linuxgrrls.org  Wed Nov 12 00:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:45:58 2005
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels@weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx@linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 

From webmaster at geschwinde.net  Wed Nov 12 14:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Fri Jun  3 17:45:58 2005
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde




From taj at linuxgrrls.org  Wed Nov 12 14:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:45:58 2005
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 

From webmaster at geschwinde.net  Wed Nov 12 15:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Fri Jun  3 17:45:58 2005
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>



From webmaster at geschwinde.net  Wed Nov 12 16:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Fri Jun  3 17:45:58 2005
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at linuxgrrls.org  Wed Nov 12 18:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:45:58 2005
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.

From c.marschalek at schrack-seconet.com  Thu Nov 13 11:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Jun  3 17:45:58 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM


From taj at www.linux.org.uk  Thu Nov 13 16:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri Jun  3 17:45:58 2005
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root@arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");



From taj at linuxgrrls.org  Thu Nov 13 16:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:45:58 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."

From webmaster at geschwinde.net  Thu Nov 13 17:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Fri Jun  3 17:45:58 2005
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>



From taj at linuxgrrls.org  Thu Nov 13 17:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:45:59 2005
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 

From c.marschalek at schrack-seconet.com  Fri Nov 14 06:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Jun  3 17:45:59 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM


From c.marschalek at schrack-seconet.com  Fri Nov 14 06:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Jun  3 17:45:59 2005
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM


From taj at linuxgrrls.org  Fri Nov 14 07:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:45:59 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.




From c.marschalek at schrack-seconet.com  Fri Nov 14 07:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Jun  3 17:45:59 2005
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM


From taj at linuxgrrls.org  Fri Nov 14 07:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:45:59 2005
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.


From taj at linuxgrrls.org  Fri Nov 14 07:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:45:59 2005
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.

From c.marschalek at schrack-seconet.com  Fri Nov 14 07:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Jun  3 17:45:59 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.


From taj at linuxgrrls.org  Fri Nov 14 07:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:45:59 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.


From halbleib at rechnerbetriebsgruppe.de  Fri Nov 14 02:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri Jun  3 17:45:59 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek@schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx



From c.marschalek at schrack-seconet.com  Fri Nov 14 08:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Jun  3 17:45:59 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(


From taj at linuxgrrls.org  Fri Nov 14 08:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:45:59 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.

From c.marschalek at schrack-seconet.com  Fri Nov 14 08:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Jun  3 17:45:59 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?


From taj at linuxgrrls.org  Fri Nov 14 08:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:45:59 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.

From c.marschalek at schrack-seconet.com  Fri Nov 14 08:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Jun  3 17:45:59 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)


From taj at linuxgrrls.org  Fri Nov 14 08:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:45:59 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.

From c.marschalek at schrack-seconet.com  Fri Nov 14 08:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Jun  3 17:45:59 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)


From c.marschalek at schrack-seconet.com  Fri Nov 14 09:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Jun  3 17:45:59 2005
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)


From taj at linuxgrrls.org  Fri Nov 14 09:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:45:59 2005
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'

From c.marschalek at schrack-seconet.com  Fri Nov 14 12:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Jun  3 17:45:59 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?


From vinu at ntcb.com  Fri Nov 14 18:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri Jun  3 17:46:00 2005
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu@ntcb.com


From taj at linuxgrrls.org  Fri Nov 14 18:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:46:00 2005
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.

From taj at linuxgrrls.org  Fri Nov 21 20:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:46:00 2005
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/


From patrick at tendim.cjb.net  Tue Nov 25 06:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri Jun  3 17:46:00 2005
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick


From dmarkman at mac.com  Wed Nov 26 05:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Fri Jun  3 17:46:00 2005
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman


From taj at linuxgrrls.org  Fri Nov 28 04:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 17:46:00 2005
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.

From patrick at tendim.cjb.net  Fri Nov 28 16:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri Jun  3 17:46:00 2005
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>


From taj at www.linux.org.uk  Fri Nov 28 21:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri Jun  3 17:46:00 2005
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj@www.linux.org.uk


From david.garnier at trusted-logic.fr  Thu Nov  6 11:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri Jun  3 18:08:16 2005
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry@12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry@12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry@12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner@12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj@www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry@12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry@12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry@12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry@12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 
From edpersson at qwest.net  Thu Nov  6 15:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri Jun  3 18:08:16 2005
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson@yahoo.com



From dmarkman at mac.com  Thu Nov  6 16:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Fri Jun  3 18:08:16 2005
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson@yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman


From dmarkman at mac.com  Thu Nov  6 17:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Fri Jun  3 18:08:17 2005
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson@yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman


From edpersson at qwest.net  Thu Nov  6 18:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri Jun  3 18:08:17 2005
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman@mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx@linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>


From dmarkman at mac.com  Thu Nov  6 19:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Fri Jun  3 18:08:17 2005
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman@mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx@linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx@linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman


From edpersson at qwest.net  Thu Nov  6 20:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri Jun  3 18:08:17 2005
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>


From dmarkman at mac.com  Thu Nov  6 21:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Fri Jun  3 18:08:17 2005
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman


From david.garnier at trusted-logic.fr  Fri Nov  7 15:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri Jun  3 18:08:17 2005
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
From edpersson at qwest.net  Fri Nov  7 21:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri Jun  3 18:08:18 2005
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
/*
* Test.class is just that.. a Test
*/


import java.io.*;
import java.util.*;
import gnu.io.*;

public class TestCrash implements SerialPortEventListener,
                                  CommPortOwnershipListener {

InputStream inputStream;
OutputStream outputStream;
SerialPort serialPort;
Thread readThread;
boolean debug = true;
boolean doDebugMessages = debug;
public static final char  FUNCTION_RESET       = 0xC1;

	public static void main(String[] args) {
		CommPortIdentifier portId;
		Enumeration portList;
		portList = CommPortIdentifier.getPortIdentifiers();
		while (portList.hasMoreElements()) {
			portId = (CommPortIdentifier) portList.nextElement();
			if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) {
                if ( portId.isCurrentlyOwned() ) {
                    System.out.println(portId.getName() + " with isCurrentlyOwned: true");
                } else {
                    System.out.println(portId.getName() + " with isCurrentlyOwned: false");
                    new TestCrash(portId);
                }
				//System.out.println(portId.getName() + " with owner: " + portId.getCurrentOwner());
			}
		}
		if (args.length < 1) {
			System.out.print("Test.class /dev/ports/serialx\n");
			System.exit(-1);
		}
		//System.out.println(System.getProperty("java.library.path"));
		//System.out.println("opening the Port: " + args[0]);		
		//Test reader = new Test(args[0]);
	}

	public TestCrash(CommPortIdentifier portId) {
        try {
            portId.addPortOwnershipListener(this);
            System.out.println(portId.getName() + " just set this as owner.");

            // get the port object
            serialPort = (SerialPort)portId.open("Test panther crash", 2000);
    
            // flow i/o
            serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE);
            outputStream  = serialPort.getOutputStream();
            inputStream   = serialPort.getInputStream();
    
            // settings
            serialPort.disableReceiveFraming();
            serialPort.disableReceiveThreshold();
            serialPort.disableReceiveTimeout();
    
            // set baud rate
            serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
                                        SerialPort.STOPBITS_1, 
                                        SerialPort.PARITY_NONE);
    
            // provide power to the device
            serialPort.setDTR(true);
            serialPort.setRTS(true);
    
            // setup the listener
            serialPort.addEventListener(this);
            //serialPort.notifyOnDataAvailable(true);
            serialPort.notifyOnOutputEmpty(true);
            serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
                                           SerialPort.STOPBITS_1, 
                                           SerialPort.PARITY_NONE);
      
            // send a break to reset DS2480
            serialPort.sendBreak(5);

            // send the timing byte
            flushCom();
            writeCom(FUNCTION_RESET);
            flushCom();

        } catch(Exception e) {
            System.err.println("Exception creating and initing serial port: " + e.getMessage());
        } finally {
            if (serialPort != null)
               serialPort.close();
    
            // failed to get the port, clean up
            portId.removePortOwnershipListener(this);
            serialPort = null;
        }
	}
   //-------------------------------------------------------------------------
   /** Write a single character to the com port
    *
    *  @param  writeVal  the data byte to write.
    *
    *  @return 'true' if byte written without error.
    */
   private boolean writeCom(char writeVal)
   {
      // provided debug on standard out
      if (doDebugMessages)
         System.out.print("W(" + Integer.toHexString(writeVal) + ")");

      try
      {
         outputStream.write((int)writeVal);
         outputStream.flush();
         return true;
      }
      catch(Exception E)
      {
         // provided debug on standard out
         System.out.println("EXCEPTION: USerialAdapter-writeCom(): " + E);
      }

      return false;
   }
    /** Flush the input and output buffer of any data
     */
    private void flushCom()
    {
      // provided debug on standard out
      if (debug)
         System.out.println("DEBUG: USerialAdapter-flush");

      try
      {
         // flush the output
         outputStream.flush();

         // flush the input buffer
         if (inputStream.available() > 0)
         {
            byte[] dummy = new byte[inputStream.available()];
            inputStream.read(dummy);
         }
      }
      catch(Exception E)
      {
         // provided debug on standard out
         System.out.println("EXCEPTION: USerialAdapter-flush: " + E);
      }
    }

	public TestCrash(String PortName) {
		RXTXCommDriver TxPort = new RXTXCommDriver();
		System.out.print("open Ports\n");		
		serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL);
		System.out.println("Get Streams from serialPort: " + serialPort);		
		try {
			inputStream = serialPort.getInputStream();
			outputStream = serialPort.getOutputStream();
		} catch (IOException e) {
			e.printStackTrace();
		}
		try {
			serialPort.addEventListener(this);
		} catch (TooManyListenersException e) {
			e.printStackTrace();
		}
		try {
			System.out.println("Baud is " + serialPort.getBaudRate());	
			System.out.println("Bits is " + serialPort.getDataBits());	
			System.out.println("Stop is " + serialPort.getStopBits());	
			System.out.println("Par is " + serialPort.getParity());	
			System.out.print("Set Params\n");		
			serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE);
			System.out.println("Baud is " + serialPort.getBaudRate());	
			System.out.println("Bits is " + serialPort.getDataBits());	
			System.out.println("Stop is " + serialPort.getStopBits());	
			System.out.println("Par is " + serialPort.getParity());	
			System.out.print("Set Params\n");		
			serialPort.setSerialPortParams(9600, SerialPort.DATABITS_7, SerialPort.STOPBITS_2, SerialPort.PARITY_ODD);
			System.out.println("Baud is " + serialPort.getBaudRate());	
			System.out.println("Bits is " + serialPort.getDataBits());	
			System.out.println("Stop is " + serialPort.getStopBits());	
			System.out.println("Par is " + serialPort.getParity());	
		} catch (UnsupportedCommOperationException e) {
			e.printStackTrace();
		}
		System.out.print("Sending 0x01\n");		
		try {
			outputStream.write((byte)0x01);
			System.out.print("0x01 Sent\n");		
		} catch (IOException e) {
			e.printStackTrace();
		}
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType()) {
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
                                System.out.print("Data Available\n");
                                break;
                }
        }

   /** Oneship change event, required to be an CommPortOwnershipListener
    *
    *  @param  type   ownership change type
    */
   public void ownershipChange(int type)
   {
      switch(type)
      {
         case PORT_OWNED:
            // provided debug on standard out
            if (debug)
               System.out.println("DEBUG: USerialAdapter-Ownership Change -  PORT_OWNED" +
                                  " by thread " + Thread.currentThread());
            break;
         case PORT_UNOWNED:
            // provided debug on standard out
            if (debug)
                System.out.println("DEBUG: USerialAdapter-Ownership Change -  PORT_UNOWNED" + 
                                   " by thread " + Thread.currentThread());
            break;
         case PORT_OWNERSHIP_REQUESTED:
            // provided debug on standard out
            if (debug)
               System.out.println("DEBUG: USerialAdapter-Ownership Change -  PORT_OWNERSHIP_REQUESTED" + 
                                  " by thread " + Thread.currentThread());
            break;
      }// switch

   }
}

-------------- next part --------------


From p_narayanamurthy at yahoo.com  Sat Nov  8 06:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri Jun  3 18:08:18 2005
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

From taj at linuxgrrls.org  Sun Nov  9 17:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:18 2005
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.



From edpersson at yahoo.com  Wed Nov  5 20:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Fri Jun  3 18:08:18 2005
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson@yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

From mba at embedded-zone.com  Thu Nov  6 12:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Fri Jun  3 18:08:18 2005
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pixie.strangenoises.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0003.htm
From ballagas at cs.rwth-aachen.de  Sun Nov  9 18:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Fri Jun  3 18:08:18 2005
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----



From taj at linuxgrrls.org  Mon Nov 10 06:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:18 2005
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.

From taj at linuxgrrls.org  Mon Nov 10 19:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:19 2005
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.

From taj at linuxgrrls.org  Mon Nov 10 19:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:19 2005
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.

From taj at linuxgrrls.org  Mon Nov 10 20:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:19 2005
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry@12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry@12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry@12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner@12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.

From john_db_adams at yahoo.com  Mon Nov 10 20:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Fri Jun  3 18:08:19 2005
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

From taj at linuxgrrls.org  Mon Nov 10 21:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:19 2005
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.


From taj at linuxgrrls.org  Mon Nov 10 21:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:19 2005
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}
From taj at linuxgrrls.org  Mon Nov 10 23:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:19 2005
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...

From edpersson at qwest.net  Tue Nov 11 02:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri Jun  3 18:08:19 2005
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>


From edpersson at qwest.net  Tue Nov 11 02:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri Jun  3 18:08:19 2005
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik


From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 21:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Fri Jun  3 18:08:19 2005
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels

From john_db_adams at yahoo.com  Tue Nov 11 15:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Fri Jun  3 18:08:19 2005
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels@weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 18:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Fri Jun  3 18:08:19 2005
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels

From taj at linuxgrrls.org  Wed Nov 12 00:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:19 2005
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels@weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx@linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 

From webmaster at geschwinde.net  Wed Nov 12 14:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Fri Jun  3 18:08:19 2005
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde




From taj at linuxgrrls.org  Wed Nov 12 14:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:20 2005
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 

From webmaster at geschwinde.net  Wed Nov 12 15:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Fri Jun  3 18:08:20 2005
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>



From webmaster at geschwinde.net  Wed Nov 12 16:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Fri Jun  3 18:08:20 2005
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at linuxgrrls.org  Wed Nov 12 18:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:20 2005
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.

From c.marschalek at schrack-seconet.com  Thu Nov 13 11:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Jun  3 18:08:20 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM


From taj at www.linux.org.uk  Thu Nov 13 16:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri Jun  3 18:08:20 2005
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root@arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");



From taj at linuxgrrls.org  Thu Nov 13 16:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:20 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."

From webmaster at geschwinde.net  Thu Nov 13 17:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Fri Jun  3 18:08:20 2005
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>



From taj at linuxgrrls.org  Thu Nov 13 17:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:20 2005
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 

From c.marschalek at schrack-seconet.com  Fri Nov 14 06:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Jun  3 18:08:20 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM


From c.marschalek at schrack-seconet.com  Fri Nov 14 06:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Jun  3 18:08:20 2005
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM


From taj at linuxgrrls.org  Fri Nov 14 07:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:20 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.




From c.marschalek at schrack-seconet.com  Fri Nov 14 07:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Jun  3 18:08:20 2005
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM


From taj at linuxgrrls.org  Fri Nov 14 07:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:20 2005
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.


From taj at linuxgrrls.org  Fri Nov 14 07:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:21 2005
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.

From c.marschalek at schrack-seconet.com  Fri Nov 14 07:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Jun  3 18:08:21 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.


From taj at linuxgrrls.org  Fri Nov 14 07:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:21 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.


From halbleib at rechnerbetriebsgruppe.de  Fri Nov 14 02:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri Jun  3 18:08:21 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek@schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx



From c.marschalek at schrack-seconet.com  Fri Nov 14 08:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Jun  3 18:08:21 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(


From taj at linuxgrrls.org  Fri Nov 14 08:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:22 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.

From c.marschalek at schrack-seconet.com  Fri Nov 14 08:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Jun  3 18:08:22 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?


From taj at linuxgrrls.org  Fri Nov 14 08:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:22 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.

From c.marschalek at schrack-seconet.com  Fri Nov 14 08:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Jun  3 18:08:22 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)


From taj at linuxgrrls.org  Fri Nov 14 08:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:22 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek@schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.

From c.marschalek at schrack-seconet.com  Fri Nov 14 08:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Jun  3 18:08:22 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)


From c.marschalek at schrack-seconet.com  Fri Nov 14 09:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Jun  3 18:08:22 2005
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)


From taj at linuxgrrls.org  Fri Nov 14 09:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:22 2005
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'

From c.marschalek at schrack-seconet.com  Fri Nov 14 12:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri Jun  3 18:08:22 2005
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?


From vinu at ntcb.com  Fri Nov 14 18:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri Jun  3 18:08:22 2005
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu@ntcb.com


From taj at linuxgrrls.org  Fri Nov 14 18:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:22 2005
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.

From taj at linuxgrrls.org  Fri Nov 21 20:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:22 2005
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/


From patrick at tendim.cjb.net  Tue Nov 25 06:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri Jun  3 18:08:22 2005
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick


From dmarkman at mac.com  Wed Nov 26 05:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Fri Jun  3 18:08:22 2005
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman


From taj at linuxgrrls.org  Fri Nov 28 04:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri Jun  3 18:08:22 2005
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.

From patrick at tendim.cjb.net  Fri Nov 28 16:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri Jun  3 18:08:23 2005
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx@linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>


From taj at www.linux.org.uk  Fri Nov 28 21:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri Jun  3 18:08:23 2005
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj@www.linux.org.uk


From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0392.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0395.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0393.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0396.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0394.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0397.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0395.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0398.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0396.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0399.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0397.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0400.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0398.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0401.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0399.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0402.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0400.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0403.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0401.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0404.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0001.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0001.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0002.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0002.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0003.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0003.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0004.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0004.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0005.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0005.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0006.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0006.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0007.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0007.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0008.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0008.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0009.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0009.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0010.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0010.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0001.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0001.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0002.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0002.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0003.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
 #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
 #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
 #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
 #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
 #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
 #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
 #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
 #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
 #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
 #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
 #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
 #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
 #16  0x000061d8 in 0x61d8
 #17  0x00003c88 in 0x3c88
 #18  0x00003afc in 0x3afc

Thread 1 Crashed:
 #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
 #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
 #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
 #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
 #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
 #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
 #6   0x03da6568 in 0x3da6568
 #7   0x03d9516c in 0x3d9516c
 #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
 #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
 #12  0x0895d0f8 in send_event (send_event + 204)
 #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
 #14  0x03d9e580 in 0x3d9e580
 #15  0x03d97e30 in 0x3d97e30
 #16  0x03d97fb0 in 0x3d97fb0
 #17  0x03d97e30 in 0x3d97e30
 #18  0x03d97fb0 in 0x3d97fb0
 #19  0x03d97e30 in 0x3d97e30
 #20  0x03d98190 in 0x3d98190
 #21  0x03d97ec0 in 0x3d97ec0
 #22  0x03d97fb0 in 0x3d97fb0
 #23  0x03d9516c in 0x3d9516c
 #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
 #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
 #28  0x00004614 in 0x4614
 #29  0x000060c4 in 0x60c4
 #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
 #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947da944 in __divdi3 (__divdi3 + 20612)
 #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
 #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
 #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d9516c in 0x3d9516c
 #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #12  0x94818868 in JVM_Close (JVM_Close + 1208)
 #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
 #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
 #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
 #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
 #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
 #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
 #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
 #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
 #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
 #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
 #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d98310 in 0x3d98310
 #10  0x03d9516c in 0x3d9516c
 #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #13  0x94818868 in JVM_Close (JVM_Close + 1208)
 #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97fb0 in 0x3d97fb0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d97e30 in 0x3d97e30
 #11  0x03d97fb0 in 0x3d97fb0
 #12  0x03d97fb0 in 0x3d97fb0
 #13  0x03d97fb0 in 0x3d97fb0
 #14  0x03d9516c in 0x3d9516c
 #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #17  0x94818868 in JVM_Close (JVM_Close + 1208)
 #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
 #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
 #1   0x90007118 in mach_msg (mach_msg + 56)
 #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
 #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
 #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
 #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
 #6   0x03d9e580 in 0x3d9e580
 #7   0x03d97fb0 in 0x3d97fb0
 #8   0x03d97ec0 in 0x3d97ec0
 #9   0x03d97ec0 in 0x3d97ec0
 #10  0x03d98310 in 0x3d98310
 #11  0x03d9516c in 0x3d9516c
 #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #14  0x94818868 in JVM_Close (JVM_Close + 1208)
 #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
 #0   0x9000b30c in select (select + 12)
 #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
 #2   0x03d9e580 in 0x3d9e580
 #3   0x03d97fb0 in 0x3d97fb0
 #4   0x03d9516c in 0x3d9516c
 #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
 #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
 #7   0x94818868 in JVM_Close (JVM_Close + 1208)
 #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
 #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
 #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
 #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
 #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
 #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
 #1   0x9000d858 in nanosleep (nanosleep + 120)
 #2   0x90012388 in usleep (usleep + 72)
 #3   0x08959864 in drain_loop (drain_loop + 60)
 #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
  srr0: 0x947bdd4c srr1: 0x0000f030               
vrsave: 0x00000000
    cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c 
ctr: 0x949dcb90
    r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430  
r3: 0x6b0274d0
    r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224  
r7: 0x947bb754
    r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0 
r11: 0x03d9e564
   r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8 
r15: 0x08959d6c
   r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834 
r19: 0xf07ff784
   r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580 
r23: 0xf07ff6d0
   r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000 
r27: 0xf07ff5d4
   r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0 
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From mba at embedded-zone.com  Thu Nov  6 05:12:29 2003
From: mba at embedded-zone.com (Moussa A. Ba)
Date: Thu, 6 Nov 2003 07:12:29 -0500
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
Message-ID: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>

Good Day,  does anybody know whether it is possible to control RTS/DTR
individually? That is, could I set and control their value (this is used
to generate a DTR reset on a board connected to the serial port).  I
would also like to use these signals to generate a sequence for
accessing the board's boot loader.  I it is impossible to do this with
the current version of RXTX, where should I look in the C code to add
such a possibility.  
 
Thank you in advance.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20031106/7c160a3c/attachment-0003.html

From ballagas at cs.rwth-aachen.de  Sun Nov  9 11:04:07 2003
From: ballagas at cs.rwth-aachen.de (Tico Ballagas)
Date: Sun, 09 Nov 2003 19:04:07 +0100
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
Message-ID: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>

Hello-

I was using the rxtx package with Mac OS X with bluetooth mounted to 
the serial port.  The problem I had is that whenever the bluetooth 
device was unavailable, the rxtx package would correctly fail to 
connect, but incorrectly held on to the lock for the serial port.  This 
prevented connection later when the bluetooth device became available.  
  I fixed this by releasing the lock on the connection error.  Note: I 
have not committed this change to CVS.

Thanks
-Tico

[media:~/sandbox/rxtx-2.0-5/src] ballagas% diff -c -3 -p SerialImp.c 
SerialImp.c.orig
*** SerialImp.c Sun Nov  9 18:43:08 2003
--- SerialImp.c.orig    Thu Oct  3 14:07:50 2002
*************** JNIEXPORT jint JNICALL RXTXPort(open)(
*** 602,608 ****
         return (jint)fd;

   fail:
-         UNLOCK( filename, pid );
         (*env)->ReleaseStringUTFChars( env, jstr, filename );
         LEAVE( "RXTXPort:open" );
         throw_java_exception( env, PORT_IN_USE_EXCEPTION, "open",
--- 602,607 ----




From taj at linuxgrrls.org  Sun Nov  9 23:33:29 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 06:33:29 +0000 (GMT)
Subject: [Rxtx] patch - omitted unlock on open failures for Mac OS X port
In-Reply-To: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
References: <1CA7ED86-12DF-11D8-B18B-000A95A67CE2@cs.rwth-aachen.de>
Message-ID: <Pine.LNX.4.58.0311100632110.1277@hex.linuxgrrls.org>



On Sun, 9 Nov 2003, Tico Ballagas wrote:

> Hello-
> 
> I was using the rxtx package with Mac OS X with bluetooth mounted to 
> the serial port.  The problem I had is that whenever the bluetooth 
> device was unavailable, the rxtx package would correctly fail to 
> connect, but incorrectly held on to the lock for the serial port.  This 
> prevented connection later when the bluetooth device became available.  
>   I fixed this by releasing the lock on the connection error.  Note: I 
> have not committed this change to CVS.
> 

Thanks Tico

I put the change into CVS as submitted.


From taj at linuxgrrls.org  Mon Nov 10 12:00:56 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:00:56 +0000 (GMT)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
References: <20031105202053.18309.qmail@web40907.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311101631460.3911@hex.linuxgrrls.org>



On Wed, 5 Nov 2003, Erik Persson wrote:

> Greetings,
> 
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
> 
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
> 
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx. 
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
> 
> A quick "Bus error" indicated that all was not well. 
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
> 
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.

There is a third party with a test suite that let me run linux/w32/solaris 
through.  It's mixed with native code so I'm not sure if its possible to 
use the test suite on Mac OS X.  If you are interested in talking to them 
about NDA's and that less fun stuff, contact me off the list.

Otherwise we just deal with bugs as they are reported :-/

> 
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment! 
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
> 
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.

I'm not sure what is going on.  My guess is something in the kernel space 
isn't thread safe.  I'll just sprinkle my comments on what I see in these 
logs below.

> 
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
> 
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1

wrote a byte.

> nativeDrain: trying tcdrain

The debug messages are not clear hear.  The tcdrain could be happening
from writeByte above or drain below.  There could be tcdrain called twice 
at the same time which somehow caused the bone pile.  flush and drain are 
the same thing as far as this goes.

> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling

see below.  this is just the event loop.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0


Timing can be strange when reporting from java and native c.  This could 
be the RXTXPort:drain() above.

> drain_loop:  writing not set
> drain_loop:  looping

The following is just select() timing out.  The evenloop is checking
for changes.  There is a eis.ret=1; in the eventLoop that does not look 
like it needs to be there which is triggering these checks.

> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0

splat.

> Bus error
> 


I've chopped out the threads not directly releated to rxtx here.  The odd 
thing to me is the repeats of threads 11 & 12 you showed.

> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
> 
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
> 
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
> 

> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

This thread just sent an output buffer empty event after calling tcdrain 
(flush in java).

> 
> Thread 12:> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags

...

> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
> 
> Thread 12:
>  #0   0x9000b30c in select (select + 12)

> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)

??? was there a copy paste error here?  Thread 11 was repeated also.

This thread is doing a select on the file descriptor for the port.  When 
it changes, events other than output buffer empty are sent on Mac OS X. 
(see below).

> 
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

This thread is sleeping.  It checks if a write has been performed
and if so, calls tcflush() on the file descriptor before notifying
the application that the output buffer is empty.

Linux has a TIOCSERGETLSR ioctl call which allows one to poke the UART LSR 
info to determine if the output buffer is empty.  Linux does not use the 
above drain_loop to determine if the buffer is empty.

Solaris and others do not have TIOCSERGETLSR so the above works around the 
problem.  TIOCSERGETLSR is not defined in standards as far as I know.


From taj at linuxgrrls.org  Mon Nov 10 12:05:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 19:05:02 +0000 (GMT)
Subject: [Rxtx] Controlling Individual Signals DTR and RTS
In-Reply-To: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
References: <001001c3a45f$406e3a80$2ba5c8d0@MUSALTOP>
Message-ID: <Pine.LNX.4.58.0311101902030.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, Moussa A. Ba wrote:

> Good Day,  does anybody know whether it is possible to control RTS/DTR
> individually? That is, could I set and control their value (this is used
> to generate a DTR reset on a board connected to the serial port).  I
> would also like to use these signals to generate a sequence for
> accessing the board's boot loader.  I it is impossible to do this with
> the current version of RXTX, where should I look in the C code to add
> such a possibility.  
>  
> Thank you in advance.
>  
> 

SerialImp.c:setRTS() SerialImp.c:setDTR() should be able to do this.  You 
could also add a native function that does everything in one shot if there 
are timing concerns.

SerialPort.setDTR() SerialPort.setRTS() are the java methods that 
correspond to the native code.


From taj at linuxgrrls.org  Mon Nov 10 13:11:07 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 20:11:07 +0000 (GMT)
Subject: [Rxtx] Error while compiling under windows
In-Reply-To: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102004420.3911@hex.linuxgrrls.org>



On Thu, 6 Nov 2003, David Garnier wrote:

> Hello,
> 
> I need to make RXTX run under Windows 2000, preferably using mingw and 
> msys. I'm already using under Linux and I'm very satisfied.
> 
> Background:
> RXTX version: rxtx-2.1-7pre16.
> Msys: 1.0.9
> Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe
> 
> There was  a few problem in the code that were easily fixed:
> -- Missing ; and char message[80] in termios.h
> -- Missing gettimeofday function: I programmed my own and included it.
> -- Defined mexPrintf to printf.
> 
> Also, I use msys instead of DOS shell so I have to modified the makefile 
> (see the attached file).
> 
> Now, my problem is that when I run make clean all I'm getting this:
> 
> 
> rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
> gnutimestamp
> mkdir include
> mkdir gnu
> mkdir gnu/io
> cp "../src"/*.* gnu/io/
> echo > gnutimestamp
> javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
> jar  -cf RXTXcomm.jar gnu/io/*.class
> javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
> include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
> gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
> gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
> gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
> gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
> gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
> gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
> gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
> gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
> gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
> gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
> gnu.io.Zystem
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
> echo "#define HAVE_FCNTL_H 1" > include/config.h
> echo "#define HAVE_SIGNAL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
> echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
> echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
> echo "#undef HAVE_TERMIOS_H" >> include/config.h
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
> In file included from ../src/SerialImp.c:45:
> ../src/gettimeofday.h: In function `gettimeofday':
> ../src/gettimeofday.h:39: warning: unused variable `tzflag'
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function 
> `Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `init_threads':
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
> ../src/SerialImp.c: In function `read_byte_array':
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
> ../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
> ../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
> ../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/termios.c -o termios.o
> gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
> /c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
> /c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
> -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
> DEBUG_TIMING -c "../src"/init.cc -o init.o
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
> -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> cp   "../src"/Serial.def gnu/io/
> ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
> termios.o init.o \
> -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
> -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
> dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
>          --base-file Serial.base --output-exp Serial.exp
> ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
> fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
> -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
> _dll_entry at 12
> Serial.exp(.edata+0xb0):fake: undefined reference to 
> `Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
> make: *** [rxtxSerial.dll] Error 1
> 
> I know enough about C and makefiles to get there, but this is kind of out 
> of my league. Any idea about ways to solve this problem?
> 
> Best Regards,
> 
> David Garnier
> 

Hi David

in psmisc/fuser.c that function needs to be stubbed for everything but 
linux at this point.

#ifndef __linux__
JNIEXPORT jstring JNICALL 
Java_javax_comm_CommPortIdentifier_native_1psmisc_1report_1owner (JNIEnv 
*env, jobject obj, jstring arg)
{
        return (*env)->NewStringUTF(env, "Unknown Application");
}
#else
... Linux code from Werner Almesberger
#endif

you will also need to link fuser.o   All this really does is report that 
the port is in use by ...

The other warnings appear harmless at first glance.


From john_db_adams at yahoo.com  Mon Nov 10 13:31:52 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Mon, 10 Nov 2003 12:31:52 -0800 (PST)
Subject: [Rxtx] win32 usb
Message-ID: <20031110203152.1535.qmail@web13208.mail.yahoo.com>

Simple question:
Can rxtx go through the usb port on win32 (I remember
reading somewhere that it can do so - with some mods -
on linux, but not win32). 
I'm communicating with a device over the serial port,
but a lot of laptops are getting rid of the db9 port
in favour of all out usb.
Thanks
joHn

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Mon Nov 10 14:32:34 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:32:34 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
References: <20031110203152.1535.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311102122500.3911@hex.linuxgrrls.org>



On Mon, 10 Nov 2003, John Adams wrote:

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32). 
> I'm communicating with a device over the serial port,
> but a lot of laptops are getting rid of the db9 port
> in favour of all out usb.
> Thanks
> joHn
> 

I've not tried w32 USB.  What is happening with Linux and Mac OS X is the 
kernel driver provides an API that allows rxtx to treat the USB device 
just as it treats rs232 cards.

It may simply be that w32 does the same thing and we just need to know the 
filename to open.

If the desire is to just do USB, you may look at the jUSB project.
http://jusb.sourceforge.net/  hmm But thats Linux only.  If you find the 
API documentation for w32 USB which shouldnt be too hard I'm sure either 
rxtx or jUSB can help get you reading and writing fast enough.



From taj at linuxgrrls.org  Mon Nov 10 14:54:03 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 21:54:03 +0000 (GMT)
Subject: [Rxtx] Still trying to run Rxtx under Windows
In-Reply-To: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
References: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>
Message-ID: <Pine.LNX.4.58.0311102141290.3911@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, David Garnier wrote:

> Hello,
> 
> I finally managed to compile the rxtx dll under Windows, but it doesn't 
> work. I can load it in the JVM, open the port and talk to it, but I'm not 
> getting anything back. I'm using this short snippet to open the port:
> 
> 
>     public static void main(String[] args) throws IOException
>     {
>        CommPortIdentifier portId = null;
>        try
>        {
>           portId = CommPortIdentifier.getPortIdentifier("COM1");
>           SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
> libcad", 2000);
> 
>           //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
> SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
>           OutputStream os = serialPort.getOutputStream();
>           os.write(1);
>           os.flush();
>           InputStream is = serialPort.getInputStream();
>           int val =is.read();
>           System.out.println("Read:" + val);
> 
>        } catch (PortInUseException e)
>        {
>           throw new CADException("Port COM1 is already used.");
>        } catch (NoSuchPortException e)
>        {
>           e.printStackTrace();
>        }
>     }
> 
> In order to see what's going on, I have attached a monitor to the serial 
> port. The log files for Javax.Comm and RXTX are attached. It seems to me 
> that RXTX does not actually tries to read data, but I don't know if this is 
> really the problem.
> 

Hi David,

What happens if you add an event listener?  There may be something thats 
not being initialized unless the listener is attached.  W32 is a little 
more involved than the Unix because of termios.c and maybe something isnt 
initialized in the code above.  I've not seen rxtx unable to read on w32.  
It is possible a bug has been introduced.  You can also try the 
precompiled libraries ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16/binaries/

Those passed faily extensive w32 (nt4, w2k, wxp, w98, wME) tests

The known issues with rxtx are:

# Baudrates of 128000 * N may have problems
# Add a method for re-checking for valid ports
# Add support in RXTX to specify valid ports on the PC.
# Adding support for half duplex serial communication.
# Error events for parity errors.
# Baudrate of 5
# serial break time
# terminating character checking for reads
# Event listeners need to be added when the port is opened to initialize 
the native structures.
# Closing a port from an event listener results in a deadlock.
# Closing a port without adding an event listener results in a deadlock.

Attached is a simple program that should be able to write and read via 
a loopback.
-------------- next part --------------
import gnu.io.*;
import java.util.*;
import java.io.InputStream;
import java.io.OutputStream;


public class Simple implements SerialPortEventListener
{
	CommPortIdentifier cpi;
    	Enumeration ports;
	SerialPort port = null;
	InputStream input;
	OutputStream output;

	public static void main( String args[] )
	{
		boolean done = false;
		Simple reader = new Simple( );
		while ( !done )
		{
			try {
				Thread.sleep(100);
			} catch (Exception e) {}
		}
	}

	public Simple( )
	{

		System.out.println("Getting PortIdentifiers");
		ports = CommPortIdentifier.getPortIdentifiers();
		while ( ports.hasMoreElements() )
		{
			cpi = (CommPortIdentifier) ports.nextElement();
			if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL)
			{
				if ( cpi.getName().equals( "/dev/ttyS1" ) )
				{
					try {
						port = (SerialPort) cpi.open("Simple", 2000);
						port.addEventListener(this);
						port.notifyOnDataAvailable(true);
						output=port.getOutputStream();
						input=port.getInputStream();
						System.out.println("writing output");
						output.write( new String("123456789\0").getBytes() );
					} catch (Exception e)
					{
						e.printStackTrace();
					}
				}
			} 
		} 
		return;
	}
        public void serialEvent(SerialPortEvent event) {
                switch(event.getEventType())
		{
                        case SerialPortEvent.BI:
                                System.out.print("BI\n");
                        case SerialPortEvent.OE:
                                System.out.print("OE\n");
                        case SerialPortEvent.FE:
                                System.out.print("FE\n");
                        case SerialPortEvent.PE:
                                System.out.print("PE\n");
                        case SerialPortEvent.CD:
                                System.out.print("CD\n");
                        case SerialPortEvent.CTS:
                                System.out.print("CTS\n");
                        case SerialPortEvent.DSR:
                                System.out.print("DSR\n");
                        case SerialPortEvent.RI:
                                System.out.print("RI\n");
                        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
                                System.out.print("Out Buff Empty\n");
                                break;
                        case SerialPortEvent.DATA_AVAILABLE:
				byte in[] = new byte[800];
				int ret = 0;


				System.out.println("Got Data Available");	
				try {
					ret = input.read( in, 0, 63 );
				} catch (Exception e) {
					System.out.println("Input Exception");				
				}
				System.out.println("Printing read() results");	
				if ( ret > 0 )
				{
					try {
						System.out.write( in, 0, ret );
						System.out.println();
					} catch ( Exception e )
					{
						e.printStackTrace();
					}
				}
				System.exit( 0 );
				break;
                }
        }
}

From taj at linuxgrrls.org  Mon Nov 10 16:19:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Mon, 10 Nov 2003 23:19:02 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
References: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311102238470.5896@hex.linuxgrrls.org>


On Fri, 7 Nov 2003, Erik Persson wrote:

> Hi All,
> 
> After looking into it off list with Dmitry, I have some more details 
> regarding the problem I described earlier.  After looking into it, I am 
> not sure if it is an OS X specific problem or not.
> 
> The attached file is a fairly simple demonstration that I built up 
> starting with contrib/Test.java.  I am using 2.1-7pre16.
> 
> I still don't have a cause identified, but the problem seems related to 
> SerialPortEventListener.  In particular, registering with 
> notifyOnOutputEmpty.
> 
> The attached file is not cleaned up, but the crash should stop when 
> commenting out line 76 where notifyOnOutputEmpty is invoked.
> 
> After registering for notifyOnOutputEmpty, a call to flush on the 
> output stream is enough to cause the problem.
> 
> When I enable debugging in RXTXPort, the problem is no longer fatal, 
> but ends up looping forever.
> 
> Here we are entering the drain code:
>    nativeDrain: trying tcdrain
>    RXTXPort:drain() returns: 0
>    send_event: !eventloop_interupted
>    send_event: jclazz
>    send_event: calling
> 
> Then the following three lines repeat forever:
>    entering check_tiocmget_changes
>    leaving check_tiocmget_changes
>    port_has_changed_fionread: change is 0
> 
> Occasionally I see:
>    drain_loop:  writing not set
>    drain_loop:  looping
> 
> Right now I am trying to get gdb to provide more insight into what is 
> going on in the jni layer, but I haven't made much progress.
> 
> Reading through SerialImp.c and looking at the output seems to indicate 
> that we are getting stuck in the RXTXPort.eventLoop native code.  This 
> code loops forever, waiting to break.  Part of the event handling code 
> in this loop calls port_has_changed_fionread.  It I am reading that 
> function correctly, the true or false return value is based on the last 
> parameter passed to ioctl.  From the log output above we can see that 
> this value is always 0 (false), so we never call send_event in 
> eventLoop.  So we go forever.
> 
> Assuming that my analysis is correct (always a dangerous assumption ;-) 
> ), does anyone have any insight into port_has_changed_fionread? and the 
> associated ioctl call?
> 
> I am happy to run tests if anyone has suggestions.
> 
> Thanks,
> Erik
> 
> 
> 

Hi Erik

These types of bugs are hard enough to figure out when you have a machine 
to test on :)

Here is what is happening in rxtx with Mac OS X (and traditional Sys V 
type Unix systems:

A port is opened and the file descriptor is stashed away in the ``event
info structure'' or eis.  This structure is what needs to be cleaned up so
that people can use rxtx without event listeners.  The eis contains info
about if a write has occured and if an output buffer event should be sent.

With the traditional Unix API there is no way to know how many bytes are 
sitting in the output waiting to go.  There is a slight problem there with 
CommAPI.  CommAPI has output buffer empty signals which can be very handy.  
To know when the output buffer is empty, rxtx sets up a seperate POSIX 
thread (pthread) that just loops until it is time to close the port.  All 
this port really does is call tcdrain() which forces data out the port and 
then sets a flag (output_buffer_empty_flag) to 1.

This loop is called drain_loop()  It will sleep for a while, call tcdrain 
and set the flag if a write has been performed.  It will run like this 
until the port is closed.

The next player is eventLoop().  This loop puts a select() on the fd.  
When the fd changes or select just times out, rxtx goes through a little 
tree of methods checking what happened and reports the events.  For this 
case its interesting to look at:

eventLoop()->report_serial_events()->check_line_status_register()

In check_line_status_register the Mac will do:

        if( eis && eis->output_buffer_empty_flag == 1 &&
                eis->eventflags[SPE_OUTPUT_BUFFER_EMPTY] )
        {
                report_verbose("check_line_status_register: sending SPE_OUTPUT_BUFFER_EMPTY\n");
                send_event( eis, SPE_OUTPUT_BUFFER_EMPTY, 1 );
                eis->output_buffer_empty_flag = 0;
        }

eventloop just spins until the port is closed also.

lots of background but not much help so far.  But at least now I remember 
how this all worked :)

Here is my guess at what is going on.  Just a starting point for 
discussion.

When you call write, rxtx will also call tcdrain() in the write functions 
to get the data out.  Now the drain loop also calls tcdrain() but its in a 
different thread.  Its my guess that tcdrain() is not thread safe for some 
reason and thats what is causing the bus error.  They both get called at 
the same time and then things bone pile up.

Setting up the notify on output buffer really does not change the flow of 
the code significantly but it may change the timing of the calls so that 
one tcdrain is called slightly later than the other.  It could be related 
to sending events but didnt look like it in the logs you posted.

So I'm curious if you can crash things after commenting the tcdrain() out 
in the drain_loop.  Leave the notify on output buffer empty true and see 
if just commenting out tcdrain does it.

-                if( tcdrain( eis->fd ) == 0 )
+		 if( 1 )
...


From edpersson at qwest.net  Mon Nov 10 19:13:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:13:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther),
	"Bus Error"  Hi Trent,
	Thanks for a good description of how things are _supposed_ to work. I
	am relieved that my first impressions about what the code was
	doing weren't totally off base! Sadly the change below does not
	seem to prevent the crash. In fact,
	I had to decrease the length of the usleep a few lines up to even get
	the code change you suggested to execute before the crash. Is
	there any crude synchronization that we could use to test the
	thread safety for the drain code? I have tried a tweaking the
	timing (by modifying or adding sleeps) in hopes of determining
	if it is timing sensitive,
	but haven't come up with anything.  It is probably straight forward,
	but my java-softened brain would likely make a lot of work out of it!
	:-) Similarly,
	I haven't had much luck getting gdb set up to debug the jnilib. Any
	ideas here? Regarding your previous comment that threads 11 &
	12 showed up three times in my list posting... I am not sure
	what to make of it. I certainly don't recall an _intentional_
	cut-n-paste error,
	but since the detailed thread dump isn't preserved (CrashReporter seems
	to keep a single copy per app),
	I can't be sure. For know it seem safe to assume that I messed it up. I
	will try to keep an eye open and see if CrashReporter seems to
	duplicate thread dumps though. -Erik On Nov 10, 2003, at 4:19 PM,
	Trent Jarvi wrote: ... So I'm curious if you can crash things after
	commenting the tcdrain() out in the drain_loop. Leave the
	notify on output buffer empty true and see if just commenting
	out tcdrain does it. - if( tcdrain( eis->fd ) == 0 ) + if( 1 )
	... _______________________________________________ Rxtx
	mailing list Rxtx@linuxgrrls.org
	http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx 
Message-ID: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>

Hi Trent,

Thanks for a good description of how things are _supposed_ to work.  I 
am relieved that my first impressions about what the code was doing 
weren't totally off base!

Sadly the change below does not seem to prevent the crash.  In fact, I 
had to decrease the length of the usleep a few lines up to even get the 
code change you suggested to execute before the crash.

Is there any crude synchronization that we could use to test the thread 
safety for the drain code?  I have tried a tweaking the timing (by 
modifying or adding sleeps) in hopes of determining if it is timing 
sensitive, but haven't come up with anything.  It is probably straight 
forward, but my java-softened brain would likely make a lot of work out 
of it!  :-)

Similarly, I haven't had much luck getting gdb set up to debug the 
jnilib.  Any ideas here?

Regarding your previous comment that threads 11 & 12 showed up three 
times in my list posting... I am not sure what to make of it.  I 
certainly don't recall an _intentional_ cut-n-paste error, but since 
the detailed thread dump isn't preserved (CrashReporter seems to keep a 
single copy per app), I can't be sure.  For know it seem safe to assume 
that I messed it up.  I will try to keep an eye open and see if 
CrashReporter seems to duplicate thread dumps though.

-Erik

On Nov 10, 2003, at 4:19 PM, Trent Jarvi wrote:
...
>
> So I'm curious if you can crash things after commenting the tcdrain() 
> out
> in the drain_loop.  Leave the notify on output buffer empty true and 
> see
> if just commenting out tcdrain does it.
>
> -                if( tcdrain( eis->fd ) == 0 )
> +		 if( 1 )
> ...
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From edpersson at qwest.net  Mon Nov 10 19:57:25 2003
From: edpersson at qwest.net (Erik Persson)
Date: Mon, 10 Nov 2003 19:57:25 -0700
Subject: [Rxtx] Testing max length of subject line.
Message-ID: <C70DB823-13F2-11D8-BDE3-003065BF1AB2@qwest.net>

Hi rxtxers,

Bet you didn't know how much you could fit in the subject line!  Ugh.

Sorry about that.

-Erik



From Mel.Bartels at weyerhaeuser.com  Mon Nov 10 14:52:33 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Mon, 10 Nov 2003 13:52:33 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>

> Simple question:
> Can rxtx go through the usb port on win32 (I remember
> reading somewhere that it can do so - with some mods -
> on linux, but not win32).

In my telescope control project, I've been using USB to RS232 serial
adapters extensively on the Windows side.  The couple of models that I've
tried have all worked fine.  

The USB port will show up in Windows and in the RXTX port enumeration as
COMx where x is the next available com port number.  For instance, on my
home machine, I have 4 USB ports available.  When I plug my USB to RS232
adapter in, I get COM3, COM4, COM5, and COM6 depending on which USB port I
use.  These numbers never change.  COM1 and COM2 are discreet RS232 ports on
my machine.

About the only parameter that I've heard anyone ever talk about manipulating
is the converter's buffer.  I've never had to.

I want to thank Trent and other contributors big time.  The whole key to my
project is telescope control via a serial bus on Windows, Mac, and Linux
variants.  Without RXTX I would have had to buy a package and rely on
commercial support, as would my users (not that that's automatically bad, of
course <smile>)...

Mel Bartels


From john_db_adams at yahoo.com  Tue Nov 11 08:38:26 2003
From: john_db_adams at yahoo.com (John Adams)
Date: Tue, 11 Nov 2003 07:38:26 -0800 (PST)
Subject: [Rxtx] win32 usb
In-Reply-To: <7BA96BB126F8B44FABDBA42A693C4F51079F88@wawtcixm10.corp.weyer.pri>
Message-ID: <20031111153826.51357.qmail@web13208.mail.yahoo.com>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.
joHn

--- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
wrote:
> > Simple question:
> > Can rxtx go through the usb port on win32 (I
> remember
> > reading somewhere that it can do so - with some
> mods -
> > on linux, but not win32).
> 
> In my telescope control project, I've been using USB
> to RS232 serial
> adapters extensively on the Windows side.  The
> couple of models that I've
> tried have all worked fine.  
> 
> The USB port will show up in Windows and in the RXTX
> port enumeration as
> COMx where x is the next available com port number. 
> For instance, on my
> home machine, I have 4 USB ports available.  When I
> plug my USB to RS232
> adapter in, I get COM3, COM4, COM5, and COM6
> depending on which USB port I
> use.  These numbers never change.  COM1 and COM2 are
> discreet RS232 ports on
> my machine.
> 
> About the only parameter that I've heard anyone ever
> talk about manipulating
> is the converter's buffer.  I've never had to.
> 
> I want to thank Trent and other contributors big
> time.  The whole key to my
> project is telescope control via a serial bus on
> Windows, Mac, and Linux
> variants.  Without RXTX I would have had to buy a
> package and rely on
> commercial support, as would my users (not that
> that's automatically bad, of
> course <smile>)...
> 
> Mel Bartels
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
>
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From Mel.Bartels at weyerhaeuser.com  Tue Nov 11 11:10:30 2003
From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel)
Date: Tue, 11 Nov 2003 10:10:30 -0800
Subject: [Rxtx] win32 usb
Message-ID: <7BA96BB126F8B44FABDBA42A693C4F5105F34C@wawtcixm10.corp.weyer.pri>

Funny, I just started looking in that direction, and
figured that's probably the route to take.
Thanks for the info though ... what models do you use
? ... I'm looking at cablemax.


I have bought several generic lowest cost usb to rs232 adapters from the
likes of Jameco and Cyberguys - about $20 - $30 US.  They all work fine in
my situation: lots of short bursty packets where delay of more than a few
milliseconds cannot be tolerated.

Mel Bartels


From taj at linuxgrrls.org  Tue Nov 11 17:05:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 00:05:04 +0000 (GMT)
Subject: [Rxtx] win32 usb
In-Reply-To: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
References: <20031111153826.51357.qmail@web13208.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0311120000210.5896@hex.linuxgrrls.org>



If what Mel said was true about usb devices showing up as comX rxtx will 
work.  I'd use it.  You can always get a refund :)

seriously though if ms or a vendor did the bits I mentioned rxtx will 
work.

Just avoid the known bugs in rxtx and things should work.  known bugs are 
are www.rxtx.org.  ya we will fix them but its easier to just change your 
code.  The price is right.

Your choice.  Thats the point of rxtx.

On Tue, 11 Nov 2003, John Adams wrote:

> Funny, I just started looking in that direction, and
> figured that's probably the route to take.
> Thanks for the info though ... what models do you use
> ? ... I'm looking at cablemax.
> joHn
> 
> --- "Bartels, Mel" <Mel.Bartels at weyerhaeuser.com>
> wrote:
> > > Simple question:
> > > Can rxtx go through the usb port on win32 (I
> > remember
> > > reading somewhere that it can do so - with some
> > mods -
> > > on linux, but not win32).
> > 
> > In my telescope control project, I've been using USB
> > to RS232 serial
> > adapters extensively on the Windows side.  The
> > couple of models that I've
> > tried have all worked fine.  
> > 
> > The USB port will show up in Windows and in the RXTX
> > port enumeration as
> > COMx where x is the next available com port number. 
> > For instance, on my
> > home machine, I have 4 USB ports available.  When I
> > plug my USB to RS232
> > adapter in, I get COM3, COM4, COM5, and COM6
> > depending on which USB port I
> > use.  These numbers never change.  COM1 and COM2 are
> > discreet RS232 ports on
> > my machine.
> > 
> > About the only parameter that I've heard anyone ever
> > talk about manipulating
> > is the converter's buffer.  I've never had to.
> > 
> > I want to thank Trent and other contributors big
> > time.  The whole key to my
> > project is telescope control via a serial bus on
> > Windows, Mac, and Linux
> > variants.  Without RXTX I would have had to buy a
> > package and rely on
> > commercial support, as would my users (not that
> > that's automatically bad, of
> > course <smile>)...
> > 
> > Mel Bartels
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx at linuxgrrls.org
> >
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 07:20:31 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 15:20:31 +0100
Subject: [Rxtx] question about actual stable version
Message-ID: <3FB241AF.3010701@geschwinde.net>

hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
for some of my linux apps.

First of all I have one question:

what is the actual stable version?
and where can I get it?

I did not get a clue. I have now a version 1.5 and now I look at 
rxtx.org a new version of 2.x is there

Maybe someone here can help me out.

Regards Ewald Geschwinde





From taj at linuxgrrls.org  Wed Nov 12 07:53:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 14:53:47 +0000 (GMT)
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB241AF.3010701@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>



rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
which was mainly w32 cleanups.

rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
enough.  Especially on linux.  www.rxtx.org will always be the latest work 
in rxtx but there is no serious effort to produce binaries on all OS's.

I encourage others to produce the binaries.  Even make money doing it.  
Just keep the source open.

On Wed, 12 Nov 2003, Ewald Geschwinde wrote:

> hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
> for some of my linux apps.
> 
> First of all I have one question:
> 
> what is the actual stable version?
> and where can I get it?
> 
> I did not get a clue. I have now a version 1.5 and now I look at 
> rxtx.org a new version of 2.x is there
> 
> Maybe someone here can help me out.
> 
> Regards Ewald Geschwinde
> 
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From webmaster at geschwinde.net  Wed Nov 12 08:15:24 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 16:15:24 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
References: <3FB241AF.3010701@geschwinde.net>
	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
Message-ID: <3FB24E8C.1030105@geschwinde.net>

thanks for the info
I'm not that java expert with compiling.

Is there a faq or how can I do this.
If it is not that difficult. I will see if I can make some binaries in 
the long term of rxtx

regards Ewald



Trent Jarvi wrote:

>rxtx 1.4 was before I took a contract to clean up some loose ends in rxtx 
>which was mainly w32 cleanups.
>
>rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>enough.  Especially on linux.  www.rxtx.org will always be the latest work 
>in rxtx but there is no serious effort to produce binaries on all OS's.
>
>I encourage others to produce the binaries.  Even make money doing it.  
>Just keep the source open.
>
>On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>
>  
>
>>hello. I'm new to this rxtx project but it sounds cool. I want tu use it 
>>for some of my linux apps.
>>
>>First of all I have one question:
>>
>>what is the actual stable version?
>>and where can I get it?
>>
>>I did not get a clue. I have now a version 1.5 and now I look at 
>>rxtx.org a new version of 2.x is there
>>
>>Maybe someone here can help me out.
>>
>>Regards Ewald Geschwinde
>>
>>
>>    
>>




From webmaster at geschwinde.net  Wed Nov 12 09:13:00 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Wed, 12 Nov 2003 17:13:00 +0100
Subject: [Rxtx] question about actual stable version
In-Reply-To: <3FB24E8C.1030105@geschwinde.net>
References: <3FB241AF.3010701@geschwinde.net>	<Pine.LNX.4.58.0311121441100.5896@hex.linuxgrrls.org>
	<3FB24E8C.1030105@geschwinde.net>
Message-ID: <3FB25C0C.7090407@geschwinde.net>

forget this mail I found the sources
thanks for your help again
regards Ewald


Ewald Geschwinde wrote:

> thanks for the info
> I'm not that java expert with compiling.
>
> Is there a faq or how can I do this.
> If it is not that difficult. I will see if I can make some binaries in 
> the long term of rxtx
>
> regards Ewald
>
>
>
> Trent Jarvi wrote:
>
>> rxtx 1.4 was before I took a contract to clean up some loose ends in 
>> rxtx which was mainly w32 cleanups.
>>
>> rxtx 2.* was the results of the work.  Some found rxtx 1.* was good 
>> enough.  Especially on linux.  www.rxtx.org will always be the latest 
>> work in rxtx but there is no serious effort to produce binaries on 
>> all OS's.
>>
>> I encourage others to produce the binaries.  Even make money doing 
>> it.  Just keep the source open.
>>
>> On Wed, 12 Nov 2003, Ewald Geschwinde wrote:
>>
>>  
>>
>>> hello. I'm new to this rxtx project but it sounds cool. I want tu 
>>> use it for some of my linux apps.
>>>
>>> First of all I have one question:
>>>
>>> what is the actual stable version?
>>> and where can I get it?
>>>
>>> I did not get a clue. I have now a version 1.5 and now I look at 
>>> rxtx.org a new version of 2.x is there
>>>
>>> Maybe someone here can help me out.
>>>
>>> Regards Ewald Geschwinde
>>>
>>>
>>>   
>>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>




From taj at linuxgrrls.org  Wed Nov 12 11:47:55 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Wed, 12 Nov 2003 18:47:55 +0000 (GMT)
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), 
In-Reply-To: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
References: <B3FA3785-13EC-11D8-BDE3-003065BF1AB2@qwest.net>
Message-ID: <Pine.LNX.4.58.0311121841200.5896@hex.linuxgrrls.org>



One thing that may be of use is the CNI code.  rxtx can be compiled with 
gcj to produce native applications.  If you can reproduce the problem with 
the CNI code, using gdb would be much easier.

The CNI code is located at:

wget -r ftp://jarvi.dsl/frii.com/pub/CNI/

if you have gcj installed, just typing make should produce a Simple 
application.  You can drop your test code in and compile a native 
application.  I know connecting gdb with the java debugger is hairy.

The only problem is the CNI code is slightly different.  It may not 
reproduce the bug.


From c.marschalek at schrack-seconet.com  Thu Nov 13 04:45:27 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Thu, 13 Nov 2003 12:45:27 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>





Hi everyone!

I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
and SimpleWrite from the Sun JavaComm help site I'm getting the following
error as soon as I start SimpleWrite (or when a Lock file is still in
/var/lock):

RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
  Please report to the RXTX developers

Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
might be able to fix it myself if I get pointed to the right locations in
the source :)



Thanks for any help provided and regards,
CM



From taj at www.linux.org.uk  Thu Nov 13 09:01:02 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Thu, 13 Nov 2003 16:01:02 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB37B06.2090106@geschwinde.net>
Message-ID: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> I have some compile problems with rxtx with j2ee1.4beta2 and arklinux 
> (www.arklinux.org)
> 
> I attach 1 file :
> 
> outsh:
> the output of the shellscript with make --version etc.
> 
> make error:
> 
> [root at arklinux rxtx-2.1-6]# make
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/javac -classpath 
> .:/home/arklinux/work/javastuff/rxtx-2.1-6:/home/arklinux/work/javastuff/rxtx-2.1-6/src: 
> -d /home/arklinux/work/javastuff/rxtx-2.1-6/ -O 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortEnumerator.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortIdentifier.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/CommPortOwnershipListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Configure.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2C.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/I2CPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/LPRPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/NoSuchPortException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/ParallelPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/PortInUseException.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/Raw.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RawPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485PortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RS485Port.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXCommDriver.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXVersion.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEvent.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPortEventListener.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialPort.java 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/UnsupportedCommOperationException.java
> Note: /home/arklinux/work/javastuff/rxtx-2.1-6/src/RXTXPort.java uses or 
> overrides a deprecated API.
> Note: Recompile with -deprecation for details.
> /usr/local/java/j2eesdk1.4_beta2/jdk//bin/jar cf RXTXcomm.jar gnu/*
> gcc -I/home/arklinux/work/javastuff/rxtx-2.1-6 -Ii686-pc-linux-gnu -I. 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include 
> -I/usr/local/java/j2eesdk1.4_beta2/jdk//include/./linux/ -g -O2 
> -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c 
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c  -fPIC -DPIC -o 
> /home/arklinux/work/javastuff/rxtx-2.1-6/i686-pc-linux-gnu/SerialImp.lo
> /home/arklinux/work/javastuff/rxtx-2.1-6/src/SerialImp.c:5078:30: 
> missing terminating " character

Hi Ewald

This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
5079.  Or escape (\) the new line like this:
                report_error("check_group_uucp(): error testing lock file \
creation Error details: ");




From taj at linuxgrrls.org  Thu Nov 13 09:00:33 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 16:00:33 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>



On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Hi everyone!
> 
> I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
> and SimpleWrite from the Sun JavaComm help site I'm getting the following
> error as soon as I start SimpleWrite (or when a Lock file is still in
> /var/lock):
> 
> RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>   Please report to the RXTX developers
> 
> Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
> might be able to fix it myself if I get pointed to the right locations in
> the source :)
> 
> 
> 
> Thanks for any help provided and regards,
> CM
> 

I suspect Suse is violating the FHS which defines where lockfiles go in 
Linux.  The directory rxtx expects the lockfiles in is located in 
SerialImp.h

#if defined(__linux__)
#       define DEVICEDIR "/dev/"
#       define LOCKDIR "/var/lock"
#       define LOCKFILEPREFIX "LCK.."
#       define FHS
#endif /* __linux__ */

You can replace /var/lock with the directory Suse is using in 8.0.

                The File System Hierarchy Standard
                http://www.pathname.com/fhs/

The current FHS lock file information is located at:

		http://www.pathname.com/fhs/2.2/fhs-5.9.html

Anyone not observing this standard in Linux is wrong.  Suse appears to be 
using "/var/spool/locks" and the FHS says: "Lock files for devices and 
other resources shared by multiple applications, such as the serial device 
lock files that were originally found in either /usr/spool/locks or 
/usr/spool/uucp, must now be stored in /var/lock."


From webmaster at geschwinde.net  Thu Nov 13 10:11:02 2003
From: webmaster at geschwinde.net (Ewald Geschwinde)
Date: Thu, 13 Nov 2003 18:11:02 +0100
Subject: [Rxtx] Re: compile problems
In-Reply-To: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3FB3BB26.9030104@geschwinde.net>

Can I download the source for this anywhere?
Regards Ewald Geschwinde

>Hi Ewald
>
>This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
>5079.  Or escape (\) the new line like this:
>                report_error("check_group_uucp(): error testing lock file \
>creation Error details: ");
>
>
>
>  
>




From taj at linuxgrrls.org  Thu Nov 13 10:19:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Thu, 13 Nov 2003 17:19:15 +0000 (GMT)
Subject: [Rxtx] Re: compile problems
In-Reply-To: <3FB3BB26.9030104@geschwinde.net>
References: <Pine.LNX.4.44.0311131557570.16209-100000@parcelfarce.linux.theplanet.co.uk>
	<3FB3BB26.9030104@geschwinde.net>
Message-ID: <Pine.LNX.4.58.0311131704540.5896@hex.linuxgrrls.org>


full package gnu.io:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz

for use with Sun's CommAPI - package javax.comm:
ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

I'll be making these easier to find at http://rxtx.qbang.org soon. Anyone
wanting to put open source projects using rxtx on yourproject.qbang.org
just drop me an email.

:q!

On Thu, 13 Nov 2003, Ewald Geschwinde wrote:

> Can I download the source for this anywhere?
> Regards Ewald Geschwinde
> 
> >Hi Ewald
> >
> >This is fixed in the rxtx 2.1-7pre releases.  Simpley joy lines 5078 and 
> >5079.  Or escape (\) the new line like this:
> >                report_error("check_group_uucp(): error testing lock file \
> >creation Error details: ");
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
> 


From c.marschalek at schrack-seconet.com  Thu Nov 13 23:20:56 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:20:56 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>





Trent Jarvi worte:

>Anyone not observing this standard in Linux is wrong.  Suse appears to be
>using "/var/spool/locks" and the FHS says: "Lock files for devices and
>other resources shared by multiple applications, such as the serial device

>lock files that were originally found in either /usr/spool/locks or
>/usr/spool/uucp, must now be stored in /var/lock."

Thanks for your answer Trent! Here's what I've found out:

Suse is in fact using the right directory since /var/spool/locks is only a
symbolic link to /var/lock.
When I delete /var/spool/locks I get another error:

"RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
exists"

Any clues what's wrong here? I don't really need lock files for my project,
but I'd rather fix this error then just evade it :)

Thanks again and best regards, CM



From c.marschalek at schrack-seconet.com  Thu Nov 13 23:23:44 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 07:23:44 +0100
Subject: Antwort: Re: [Rxtx] Re: compile problems
Message-ID: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>





Trent Jarvi worte:
>full package gnu.io:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
>
>for use with Sun's CommAPI - package javax.comm:
>ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz

Can you (or anyone else) please tell me where the differences are? Is using
Sun's CommAPI better for compatibility reasons or anything like that?

Thanks, CM



From taj at linuxgrrls.org  Fri Nov 14 00:00:52 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:00:52 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
References: <OF42792B5D.D1A86594-ONC1256DDE.00227D6E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140648420.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> 
> >Anyone not observing this standard in Linux is wrong.  Suse appears to be
> >using "/var/spool/locks" and the FHS says: "Lock files for devices and
> >other resources shared by multiple applications, such as the serial device
> 
> >lock files that were originally found in either /usr/spool/locks or
> >/usr/spool/uucp, must now be stored in /var/lock."
> 
> Thanks for your answer Trent! Here's what I've found out:
> 
> Suse is in fact using the right directory since /var/spool/locks is only a
> symbolic link to /var/lock.
> When I delete /var/spool/locks I get another error:
> 
> "RTXT fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File
> exists"
> 
> Any clues what's wrong here? I don't really need lock files for my project,
> but I'd rather fix this error then just evade it :)
> 


here is what happens with rxtx and lockfiles:

It checks a boatload of ~possible~ directories lock files have been known 
to hide in.  This was how the symbolic link caused problems.  There could 
have been an older version of kermit for instance using the port.  Perhaps 
its possible to not follow symbolic links in rxtx.

If anything unexpected with lockfiles happens rxtx bails with error as you 
saw.

Next if there is an expected lockfile, rxtx checks the PID on linux.  If 
the process is still around, rxtx will bail.  If the process is dead, rxtx 
will try to remove the lock file.

finally rxtx will try to lock the port by creating the lockfile.

So I'm curious.  As the same user that started the application, look at 
the lockfile thats there, see if the process is active, see if the user 
can delete the file and finally see if you can create a file in the lock 
directory.  It should be fairly easy to see where things go wrong.





From c.marschalek at schrack-seconet.com  Fri Nov 14 00:17:35 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:17:35 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>





Trent Jarvi wrote:
>So I'm curious.  As the same user that started the application, look at
>the lockfile thats there, see if the process is active, see if the user
>can delete the file and finally see if you can create a file in the lock
>directory.  It should be fairly easy to see where things go wrong.

Well there's a lock file in "/var/lock" and it contains the correct pid for
the java program which is using the port (SimpleRead)
The lockfile can be created and deleted in the directory by the user
running the java program and still SimpleWrite (running with the same user)
tells me that he can't create the lock file rather than that the port is in
use (because the lock file contains the right pid)

Weird huh?

regards, CM



From taj at linuxgrrls.org  Fri Nov 14 00:12:15 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:12:15 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] Re: compile problems
In-Reply-To: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
References: <OF43E74D15.25160107-ONC1256DDE.0022FEB4@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140701140.23454@hex.linuxgrrls.org>

On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi worte:
> >full package gnu.io:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.1-7pre17.tar.gz
> >
> >for use with Sun's CommAPI - package javax.comm:
> >ftp://jarvi.dsl.frii.com/pub/rxtx/rxtx-2.0-7pre1.tar.gz
> 
> Can you (or anyone else) please tell me where the differences are? Is using
> Sun's CommAPI better for compatibility reasons or anything like that?
> 

It is more a matter of personal choice.  2.1 is 100% LGPL and CommAPI
compatible except the package it is in (javax.comm vs gnu.io to avoid any   
possible problems with sun's clickthrough license).

rxtx 2.0 fits into the Sun package so you can use javax.comm.  The native
code is essentially identical.

It really depends upon which licenses you want to use; the choice is 
left to you.  The 2.0 code has been a bit behind in the past as there was 
significant interests in getting fixes into 2.1.  They should be in sync 
now.  There may be some easy to fix problems in 2.0 that are not caught 
yet.



From taj at linuxgrrls.org  Fri Nov 14 00:22:04 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:22:04 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
References: <OF5A962CC4.0AEB1B28-ONC1256DDE.00276DF5@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140713370.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >So I'm curious.  As the same user that started the application, look at
> >the lockfile thats there, see if the process is active, see if the user
> >can delete the file and finally see if you can create a file in the lock
> >directory.  It should be fairly easy to see where things go wrong.
> 
> Well there's a lock file in "/var/lock" and it contains the correct pid for
> the java program which is using the port (SimpleRead)
> The lockfile can be created and deleted in the directory by the user
> running the java program and still SimpleWrite (running with the same user)
> tells me that he can't create the lock file rather than that the port is in
> use (because the lock file contains the right pid)
> 

ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont 
work.  Lockfiles don't know if you are reading or writing.  They just know 
only one program can have the port.

For experimenting you could configure rxtx with lockfiles disabled to try 
using both programs on the port at the same time.

	configure --disable-lockfiles

It's not advisable to use that for normal use but you can try it.  What
can end up happening is two people end up fighting over data on a port.  
Or maybe an application that was forgotten reads every other byte causing
all sorts of confusion and frustration.


From c.marschalek at schrack-seconet.com  Fri Nov 14 00:33:14 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 08:33:14 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>





Trent Jarvi wrote:
>ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont

>work.  Lockfiles don't know if you are reading or writing.  They just know

>only one program can have the port.

Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
SimpleWrite!
The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
But SimpleWrite is bailing when detecting the ports (at least it seems so)

I'll pate the code if you like, but I just changed the defaultPort String
in both.



From taj at linuxgrrls.org  Fri Nov 14 00:32:32 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 07:32:32 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
References: <OF4015520E.CAFCBA1A-ONC1256DDE.002925DE@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140729320.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >ah.. You want to open the port with SimpleRead and SimpleWrite.  That wont
> 
> >work.  Lockfiles don't know if you are reading or writing.  They just know
> 
> >only one program can have the port.
> 
> Well actually I'm using /dev/ttyS0 in SimpleRead and /dev/ttyS1 in
> SimpleWrite!
> The two programs do work as SimpleRead gets the stuff SimpleWrite sends.
> But SimpleWrite is bailing when detecting the ports (at least it seems so)
> 
> I'll pate the code if you like, but I just changed the defaultPort String
> in both.
> 

If the programs are started at the same time, the enumerations could 
conflict.  rxtx locks each port as it checks if the port is usable.  They 
could both be checking the same ports.  hmm or one may have a port and the 
second is just mentioning that it is locked as it tries to enumerate.

That would be ok.  If SimpleRead locks a port and SimpleWrite tries to 
enumerate ports, we still want the message so people know why that port 
did not enumerate.



From halbleib at rechnerbetriebsgruppe.de  Thu Nov 13 19:15:33 2003
From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib)
Date: Fri, 14 Nov 2003 03:15:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
References: <OFB19ADB6B.C8A0168F-ONC1256DDD.0040009E@schrack-seconet.com>
	<Pine.LNX.4.58.0311131552270.5896@hex.linuxgrrls.org>
Message-ID: <3FB43AC5.8000004@rechnerbetriebsgruppe.de>

> 
> On Thu, 13 Nov 2003 c.marschalek at schrack-seconet.com wrote:
> 
> 
>>
>>
>>
>>Hi everyone!
>>
>>I'm using rxtx-2.1-6 on a SuSE 8.2 system and when I'm running SimpleRead
>>and SimpleWrite from the Sun JavaComm help site I'm getting the following
>>error as soon as I start SimpleWrite (or when a Lock file is still in
>>/var/lock):
>>
>>RXTX Error: Unexpected lock file: /var/spool/locks/LCK..ttyS0
>>  Please report to the RXTX developers
>>
>>Can't RXTX handle SuSE 8.2 lock files or is there something else wrong? I
>>might be able to fix it myself if I get pointed to the right locations in
>>the source :)
>>
>>
>>
>>Thanks for any help provided and regards,
>>CM
>>
> 
> 
> I suspect Suse is violating the FHS which defines where lockfiles go in 
> Linux.  The directory rxtx expects the lockfiles in is located in 
> SerialImp.h
> 
> #if defined(__linux__)
> #       define DEVICEDIR "/dev/"
> #       define LOCKDIR "/var/lock"
> #       define LOCKFILEPREFIX "LCK.."
> #       define FHS
> #endif /* __linux__ */
> 
> You can replace /var/lock with the directory Suse is using in 8.0.
> 
>                 The File System Hierarchy Standard
>                 http://www.pathname.com/fhs/
> 
> The current FHS lock file information is located at:
> 
> 		http://www.pathname.com/fhs/2.2/fhs-5.9.html
> 
> Anyone not observing this standard in Linux is wrong.  Suse appears to be 
> using "/var/spool/locks" and the FHS says: "Lock files for devices and 
> other resources shared by multiple applications, such as the serial device 
> lock files that were originally found in either /usr/spool/locks or 
> /usr/spool/uucp, must now be stored in /var/lock."

my SuSE 8.2 use "/var/lock/"

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx




From c.marschalek at schrack-seconet.com  Fri Nov 14 01:14:25 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:14:25 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>





Trent Jarvi wrote:
>If the programs are started at the same time, the enumerations could
>conflict.  rxtx locks each port as it checks if the port is usable.  They
>could both be checking the same ports.  hmm or one may have a port and the

>second is just mentioning that it is locked as it tries to enumerate.

>That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
>enumerate ports, we still want the message so people know why that port
>did not enumerate.

SimpleWrite displays the error (cant create lock file) when executing this
command:

"portList = CommPortIdentifier.getPortIdentifiers();"

I still dont understand why rxtx wants to create a lockfile for a port it
doesn't use :(



From taj at linuxgrrls.org  Fri Nov 14 01:17:43 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:17:43 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
References: <OF162F19BB.D197BA23-ONC1256DDE.002A1498@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140812060.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> >If the programs are started at the same time, the enumerations could
> >conflict.  rxtx locks each port as it checks if the port is usable.  They
> >could both be checking the same ports.  hmm or one may have a port and the
> 
> >second is just mentioning that it is locked as it tries to enumerate.
> 
> >That would be ok.  If SimpleRead locks a port and SimpleWrite tries to
> >enumerate ports, we still want the message so people know why that port
> >did not enumerate.
> 
> SimpleWrite displays the error (cant create lock file) when executing this
> command:
> 
> "portList = CommPortIdentifier.getPortIdentifiers();"
> 
> I still dont understand why rxtx wants to create a lockfile for a port it
> doesn't use :(
> 


The behaviour of rxtx on Linux is transitional.  The kernel knows what the 
valid ports are.  In the future (well if you are a hacker with the latest 
kernels its there) the kernel will export this info and rxtx will just 
look to see whats available.  With current distro's rxtx has to 'test' the 
port.  That involves opening the port.  If you open the port you have to 
lock it.  Thats my understanding.  Also rxtx tries a timed out read after 
opening the port and if that errors rather than times out, rxtx will 
not enumerate the port.

To avoid this behavior just avoid enumeration.  ie getPortIdentifiers();
but the behavior will change as the new kernels move into stable use.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:28:31 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:28:31 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>





Trent Jarvi wrote:

>With current distro's rxtx has to 'test' the port. That involves opening
the port.
What are the lock files good for then? rxtx shouldn't test the port if
there's a lock file for it, should it?



From taj at linuxgrrls.org  Fri Nov 14 01:26:44 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:26:44 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
References: <OF86DAA95C.D56C9052-ONC1256DDE.002E574D@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140823230.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> Trent Jarvi wrote:
> 
> >With current distro's rxtx has to 'test' the port. That involves opening
> the port.
> What are the lock files good for then? rxtx shouldn't test the port if
> there's a lock file for it, should it?

rxtx wont test a locked port.  But it will give the message that it 
couldn't create the lock file.  This is very handy if you work with 
multiple ports/applications.  You may have an application running in the 
background and just stare at rxtx when it silently exits at the command 
line if we dont give a message.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:35:13 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:35:13 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>





> Trent Jarvi wrote:
>rxtx wont test a locked port.  But it will give the message that it
>couldn't create the lock file.  This is very handy if you work with
>multiple ports/applications.  You may have an application running in the
>background and just stare at rxtx when it silently exits at the command
>line if we dont give a message.

aahh so there's the confusing thing.. instead of saying that the port is
locked by another process it tells me that it cant create the lock file...
little confusing but now I understand what's going on :)

Thanks for all your replies :)



From taj at linuxgrrls.org  Fri Nov 14 01:37:45 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 08:37:45 +0000 (GMT)
Subject: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
References: <OF762E700B.10C7DEF3-ONC1256DDE.002F057E@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140833090.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003 c.marschalek at schrack-seconet.com wrote:

> 
> 
> 
> 
> > Trent Jarvi wrote:
> >rxtx wont test a locked port.  But it will give the message that it
> >couldn't create the lock file.  This is very handy if you work with
> >multiple ports/applications.  You may have an application running in the
> >background and just stare at rxtx when it silently exits at the command
> >line if we dont give a message.
> 
> aahh so there's the confusing thing.. instead of saying that the port is
> locked by another process it tells me that it cant create the lock file...
> little confusing but now I understand what's going on :)
> 
> Thanks for all your replies :)
> 

which version was this?  I worked out an agreement with Werner Almesberger 
to use his fuser code in rxtx to report "Port $x is in use by $user ...".  
Maybe I just need to add the same function call for enumeration.

I thought that was done.


From c.marschalek at schrack-seconet.com  Fri Nov 14 01:52:33 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 09:52:33 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OF5FCE74BD.D49EA260-ONC1256DDE.0030A2E4@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I'm using 2.1-6 right now, I'll install 2.1-7pre and try it again :)



From c.marschalek at schrack-seconet.com  Fri Nov 14 02:09:26 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 10:09:26 +0100
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>





Trent Jarvi wrote:
>which version was this?  I worked out an agreement with Werner Almesberger

>to use his fuser code in rxtx to report "Port $x is in use by $user ...".

>Maybe I just need to add the same function call for enumeration.
>I thought that was done.

I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
TWICE :)



From taj at linuxgrrls.org  Fri Nov 14 02:10:47 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 09:10:47 +0000 (GMT)
Subject: Antwort: Re: [Rxtx] RXTX Error: Unexpected lock file
In-Reply-To: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
References: <OFC3B7D065.46E55E74-ONC1256DDE.00322D79@schrack-seconet.com>
Message-ID: <Pine.LNX.4.58.0311140905110.23454@hex.linuxgrrls.org>


> >Maybe I just need to add the same function call for enumeration.
> >I thought that was done.
> 
> I tried it with 2.1-pre16 and 2.1-pre17 and now I get the same error but
> TWICE :)
> 

OK.  I'll look at the enumeration code in a few hours.

There is no reason we can't report the port, user and PID thats blocking
enumeration.  Its all there.  I guess we only do it on 'open()'


From c.marschalek at schrack-seconet.com  Fri Nov 14 05:25:07 2003
From: c.marschalek at schrack-seconet.com (c.marschalek@schrack-seconet.com)
Date: Fri, 14 Nov 2003 13:25:07 +0100
Subject: [Rxtx] RXTX Error: Unexpected lock file
Message-ID: <OFAB8CB9F6.5D7CDA43-ONC1256DDE.00441DD4@schrack-seconet.com>





Trent Jarvi worte:
>OK.  I'll look at the enumeration code in a few hours.

>There is no reason we can't report the port, user and PID thats blocking
>enumeration.  Its all there.  I guess we only do it on 'open()'

Ok thanks then :)

Off topic, do you know why Sun decided to not support the linux platform
with their CommApi?



From vinu at ntcb.com  Fri Nov 14 11:14:50 2003
From: vinu at ntcb.com (vinu)
Date: Fri, 14 Nov 2003 12:14:50 -0600
Subject: [Rxtx] Not finding com port on window98 
Message-ID: <200311141207544.SM00940@there>

Hi !


I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
running JavaKit using following  command.


java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
2097152 -allow


I got it running,  but it is not showing any  COM Port  in the list and it is 
not giving any error on the consol.


I am wondering what could be the reason?

On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
ttyS1.


I wrote a test program "PortListener.java"  It is running without error, but 
not listing any port.

Thanks.


Vinu Vaghasia
---------------------
Invision Networks Inc.
E-mail:vinu at ntcb.com



From taj at linuxgrrls.org  Fri Nov 14 11:21:36 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 14 Nov 2003 18:21:36 +0000 (GMT)
Subject: [Rxtx] Not finding com port on window98 
In-Reply-To: <200311141207544.SM00940@there>
References: <200311141207544.SM00940@there>
Message-ID: <Pine.LNX.4.58.0311141818520.23454@hex.linuxgrrls.org>



On Fri, 14 Nov 2003, vinu wrote:

> Hi !
> 
> 
> I installed j2sdk1.4.2,  tini1.11 and javax.comm  on my window98.  I am 
> running JavaKit using following  command.
> 
> 
> java  -classpath <TINIDIR>\bin\tini.jar JavaKit -400 -flash 40 -ROMSize 
> 2097152 -allow
> 
> 
> I got it running,  but it is not showing any  COM Port  in the list and it is 
> not giving any error on the consol.
> 
> 
> I am wondering what could be the reason?
> 
> On Linux, with the same command it is working ok.  On Linux it shows  ttyS0 & 
> ttyS1.
> 
> 
> I wrote a test program "PortListener.java"  It is running without error, but 
> not listing any port.
> 
> Thanks.
> 
> 

Hi Vinu

have you placed the javax.comm.properties file in the right location?

With rxtx make sure you use the Solaris version of CommAPI not the 
windows version.

Also make sure you have the ports enabled in bios and the windows system 
has detected them.


From taj at linuxgrrls.org  Fri Nov 21 13:56:02 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 21 Nov 2003 20:56:02 +0000 (GMT)
Subject: [Rxtx] Third party rxtx RPMS
Message-ID: <Pine.LNX.4.58.0311211927350.7753@hex>


debian already has packages but for those liking RPMs...

Gabriel Matter writes:

By the way my brother made an rpm-package that sets the library path and
puts the libfiles in /usr/lib/java to have lesser problems when
upgrading the jdk... available at

http://www.invoca.ch/pub/packages/rxtx/



From patrick at tendim.cjb.net  Mon Nov 24 23:37:15 2003
From: patrick at tendim.cjb.net (tendim)
Date: Tue, 25 Nov 2003 01:37:15 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X (Jaguar)
Message-ID: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>

Hello all.

With some effort I have managed to compile the latest RXTX from CVS 
under MacOS 10.2.8 (Jaguar).

However, when I try to execute the test program from SUN (SimpleWrite), 
or the following program:

<!-- START -->

import javax.comm.*;
import java.io.*;

public class ScanPorts {

         public static void main(String args[]) {
                 System.out.println("Hello, world.");
                 scan();
         }

         private static void scan() {
                 try {
                         int index=0;
                         java.util.Enumeration en = 
CommPortIdentifier.getPortIdentifiers();
                         while (en.hasMoreElements()) {
                                 CommPortIdentifier portID = 
(CommPortIdentifier)(en.nextElement());
                                 if (portID==null) continue;
                                 if (portID.getPortType() == 
CommPortIdentifier.PORT_SERIAL) {
                                         String name = portID.getName();
                                         System.out.println(name);
                                 }
                         }
                 } catch (Exception e) {}
         }
}

<!-- END -->

I get the following error:

<!-- START -->

Devel Library
=========================================
Native lib Version = RXTX-2.0-7pre1
Java lib Version   = RXTX-2.0-7pre1
getMethodID of CommDriver.addPortName failed
Caught java.lang.NoSuchMethodError: addPortName while loading driver 
gnu.io.RXTXCommDriver
Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
while loading driver com.sun.comm.SolarisDriver

<!-- END -->

I should note that when I was completing the installation instructions, 
the following script would not work:

<!-- START -->

#!/bin/sh
curruser=`sudo id -p | grep 'login' | sed 's/login.//'`

if [ ! -d /var/spool/uucp ]
then
sudo mkdir /var/spool/uucp
fi

sudo chgrp uucp /var/spool/uucp
sudo chmod 775 /var/spool/uucp
if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
/dev/null` ]
then
  sudo niutil -mergeprop / /groups/uucp users $curruser
fi

<!-- END -->

Although, I am part of the group 'uucp'.

Can anyone suggest what I am doing wrong?  The program's compile 
without any problems, with the typical "javac ScanPorts.java".  I am 
executing with "java ScanPorts" from the same directory containing 
ScanPorts.class.

Cheers,
Patrick



From dmarkman at mac.com  Tue Nov 25 22:17:34 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Wed, 26 Nov 2003 00:17:34 -0500
Subject: [Rxtx] Palm Emulator and RXTX on Mac OS X
Message-ID: <D7B66680-1FCF-11D8-91CB-000A95DA5E9C@mac.com>

to whom in may concern :-)


as you probably know Palm Emulator on Mac OS X can't work with any 
external devices (because Palm Emulator is Carbon application)
however it's possible to connect to POSE through TCP/IP, so here is a 
story:

we have some application that works on PDA and that application have to 
communicate with some interface
via Palm's serial port

we wanted setup our application to work on Palm Emulator with interface
connected to the computer via usb-serial adapter

so I setup PalmEmulator to emulate communication through serial port as 
TCP/IP connection via localhost:6416
from other hand I created small java proxy application that listen 6416 
port

so when our palm application requires serial port PalmEmulator connects 
to my proxy application
and I launch 2 threads:
1. reads from 6416 port and writes to serial-usb port (RXTX 2.1.X)
2. reads from serial-usb port (RXTX 2.1.X) and writes to 6416 port

and to my big surprise it works without any glitches

hope that information will be useful for somebody



Dmitry Markman



From taj at linuxgrrls.org  Thu Nov 27 21:22:51 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Fri, 28 Nov 2003 04:22:51 +0000 (GMT)
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
References: <CEFFD2D8-1F11-11D8-B038-003065B58BC0@tendim.cjb.net>
Message-ID: <Pine.LNX.4.58.0311280420430.22901@hex>



On Tue, 25 Nov 2003, tendim wrote:

> Hello all.
> 
> With some effort I have managed to compile the latest RXTX from CVS 
> under MacOS 10.2.8 (Jaguar).
> 
> However, when I try to execute the test program from SUN (SimpleWrite), 
> or the following program:
> 
> <!-- START -->
> 
> import javax.comm.*;
> import java.io.*;
> 
> public class ScanPorts {
> 
>          public static void main(String args[]) {
>                  System.out.println("Hello, world.");
>                  scan();
>          }
> 
>          private static void scan() {
>                  try {
>                          int index=0;
>                          java.util.Enumeration en = 
> CommPortIdentifier.getPortIdentifiers();
>                          while (en.hasMoreElements()) {
>                                  CommPortIdentifier portID = 
> (CommPortIdentifier)(en.nextElement());
>                                  if (portID==null) continue;
>                                  if (portID.getPortType() == 
> CommPortIdentifier.PORT_SERIAL) {
>                                          String name = portID.getName();
>                                          System.out.println(name);
>                                  }
>                          }
>                  } catch (Exception e) {}
>          }
> }
> 
> <!-- END -->
> 
> I get the following error:
> 
> <!-- START -->
> 
> Devel Library
> =========================================
> Native lib Version = RXTX-2.0-7pre1
> Java lib Version   = RXTX-2.0-7pre1
> getMethodID of CommDriver.addPortName failed
> Caught java.lang.NoSuchMethodError: addPortName while loading driver 
> gnu.io.RXTXCommDriver
> Caught java.lang.ClassCircularityError: javax.comm/CommPortIdentifier 
> while loading driver com.sun.comm.SolarisDriver
> 
> <!-- END -->
> 
> I should note that when I was completing the installation instructions, 
> the following script would not work:
> 
> <!-- START -->
> 
> #!/bin/sh
> curruser=`sudo id -p | grep 'login' | sed 's/login.//'`
> 
> if [ ! -d /var/spool/uucp ]
> then
> sudo mkdir /var/spool/uucp
> fi
> 
> sudo chgrp uucp /var/spool/uucp
> sudo chmod 775 /var/spool/uucp
> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > 
> /dev/null` ]
> then
>   sudo niutil -mergeprop / /groups/uucp users $curruser
> fi
> 
> <!-- END -->
> 
> Although, I am part of the group 'uucp'.
> 
> Can anyone suggest what I am doing wrong?  The program's compile 
> without any problems, with the typical "javac ScanPorts.java".  I am 
> executing with "java ScanPorts" from the same directory containing 
> ScanPorts.class.
> 

Did you double check that javax.comm.properties is properly installed?
This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's 
CommAPI for Solaris.


From patrick at tendim.cjb.net  Fri Nov 28 09:16:21 2003
From: patrick at tendim.cjb.net (tendim)
Date: Fri, 28 Nov 2003 11:16:21 -0500
Subject: [Rxtx] java.lang.noSuchMethodError exception under Mac OS X
	(Jaguar)
In-Reply-To: <Pine.LNX.4.58.0311280420430.22901@hex>
Message-ID: <344CB61C-21BE-11D8-8A19-003065B58BC0@tendim.cjb.net>

Hi.
On Thursday, November 27, 2003, at 11:22 PM, Trent Jarvi wrote:
> Did you double check that javax.comm.properties is properly installed?
> This file is not required by rxtx 2.1 but is with rxtx-2.0 and Sun's
> CommAPI for Solaris.

Yes, I installed it in 
/System/Library/Frameworks/JavaVM.framework/Home/lib as described in 
the README.MacOSX file.  Still no luck, however.

> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>



From taj at www.linux.org.uk  Fri Nov 28 14:18:13 2003
From: taj at www.linux.org.uk (taj@www.linux.org.uk)
Date: Fri, 28 Nov 2003 21:18:13 +0000 (GMT)
Subject: [Rxtx] RXTX on win32 with new UNC-Style ports (was rxtx)
In-Reply-To: <3FC7B41E.4020406@swissonline.ch>
Message-ID: <Pine.LNX.4.44.0311282106460.31628-100000@parcelfarce.linux.theplanet.co.uk>

On Fri, 28 Nov 2003, Philipp Bucher wrote:

> Hi Trent
> 
> Thank you for providing rxtx to the opensoftware community,
> i used binary versions of rxtx successfuly on win32
> and self-compiled versions on Linux and OS X.
> 
> Now i have to integrate a pcmcia-card (RS232) on a  win32,
> the port-naming is UNC-Style eg. \\.\card0 ----> in java \\\\.\\card0 !
> 
> Now i asume when the portname travels through jni to C some thing
> gets messedup with all these backslaches and the serialPort is null after
> serPort = (SerialPort)driver.getCommPort("\\\\.\\card0", 
> CommPortIdentifier.PORT_SERIAL);
> 
> so i am trying to crosscompile rxtx from a SuSE 8 to win32
> to put in debug printf's to sort out the problem but when i do
> make it fails with the following notice:
> 
> make: *** [i386-pc-mingw32/rxtxSerial.dll] Error 1
> 
> Could you give me a fingertip where to dig-down or what
> i am doing wrong.
> 
> many thanks in advance
> Philipp
> 
> 
> what i did:
> 
> rpm -i crossmingw32-990111-1.i386.rpm
> export WIN32INCLUDE=/home/pipo/ereader/rxtx/win32java/include
> export PATH=/usr/i386-mingw32/bin:$PATH
> 
> export 
> CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot
> cvs login
> mousy
> 
> cvs checkout -r commapi-0-0-1 rxtx-devel
> cd rxtx-devel
> mkdir build
> cd build
> 
> ../configure --target=i386-mingw32 --host=i386-pc-linux --build=i386-mingw32
> make
> 
> 
> 

Hi Philipp

Hi philip:

/usr/i386-mingw32/include/dir.h:61: `time_t' undeclared (first use in this 
function)
/usr/i386-mingw32/include/dir.h:61: (Each undeclared identifier is 
reported only
once

I think this is suggesting #include <sys/time.h> is missing.  Try adding 
that or #include <time.h> to the top of SerialImp.c.  The modifications 
will need to be made to RXTXCommDriver.java so you may not need to compile 
the native library at all; just the jar.


This is probably what you want to look at in RXTXCommDriver.java.  Without 
reading the code in detail, I suspect these are the changes you need.

               else if(osName.toLowerCase().indexOf("windows") != -1 )
                {
                        String[] temp = new String[259];
                        for( int i = 1; i <= 256; i++ )
                        {
                                temp[i - 1] = new String( "COM" + i );
                        }
+                        for( int i = 1; i <= 256; i++ )
+                        {
+                                temp[i - 1] = new String( "//./card" + i );
+                        }

                        for( int i = 1; i <= 3; i++ )
                        {
                                temp[i + 255] = new String( "LPT" + i );
                        }
                        CandidateDeviceNames=temp;
                        }

...

                                        else if(osName.toLowerCase().indexOf("windows") != -1 )
                                        {
                                                String[] Temp = {
                                                        "COM",     // win32 serial ports
+							"//./card"
                                                        //"//./COM"    // win32 serial ports
                                        };
                                        CandidatePortPrefixes=Temp;


-- 
Trent Jarvi
taj at www.linux.org.uk



From david.garnier at trusted-logic.fr  Thu Nov  6 04:07:33 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Thu, 06 Nov 2003 12:07:33 +0100
Subject: [Rxtx] Error while compiling under windows
Message-ID: <5.2.0.9.0.20031106113900.02b6ad38@mail.trusted-logic.fr>

Hello,

I need to make RXTX run under Windows 2000, preferably using mingw and 
msys. I'm already using under Linux and I'm very satisfied.

Background:
RXTX version: rxtx-2.1-7pre16.
Msys: 1.0.9
Mingw: <http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download>3.1.0-1.exe

There was  a few problem in the code that were easily fixed:
-- Missing ; and char message[80] in termios.h
-- Missing gettimeofday function: I programmed my own and included it.
-- Defined mexPrintf to printf.

Also, I use msys instead of DOS shell so I have to modified the makefile 
(see the attached file).

Now, my problem is that when I run make clean all I'm getting this:


rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o 
gnutimestamp
mkdir include
mkdir gnu
mkdir gnu/io
cp "../src"/*.* gnu/io/
echo > gnutimestamp
javac -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar gnu/io/*.java
jar  -cf RXTXcomm.jar gnu/io/*.class
javah -classpath .:"/c/j2sdk1.4.1_02-rxtx//jre/lib/ext"/comm.jar -jni -d 
include gnu.io.CommDriver gnu.io.CommPort gnu.io.CommPortEnumerator 
gnu.io.CommPortIdentifier gnu.io.CommPortOwnershipListener gnu.io.Configure 
gnu.io.I2C gnu.io.I2CPort gnu.io.I2CPortEvent gnu.io.I2CPortEventListener 
gnu.io.LPRPort gnu.io.NoSuchPortException gnu.io.ParallelPort 
gnu.io.ParallelPortEvent gnu.io.ParallelPortEventListener 
gnu.io.PortInUseException gnu.io.RS485 gnu.io.RS485Port 
gnu.io.RS485PortEvent gnu.io.RS485PortEventListener gnu.io.RXTXCommDriver 
gnu.io.RXTXPort gnu.io.RXTXVersion gnu.io.Raw gnu.io.RawPort 
gnu.io.RawPortEvent gnu.io.RawPortEventListener gnu.io.SerialPort 
gnu.io.SerialPortEvent gnu.io.SerialPortEventListener 
gnu.io.UnSupportedLoggerException gnu.io.UnsupportedCommOperationException 
gnu.io.Zystem
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/fixup.c -o fixup.o
echo "#define HAVE_FCNTL_H 1" > include/config.h
echo "#define HAVE_SIGNAL_H 1" >> include/config.h
echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
echo "#undef HAVE_TERMIOS_H" >> include/config.h
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/SerialImp.c -o SerialImp.o
In file included from ../src/SerialImp.c:45:
../src/gettimeofday.h: In function `gettimeofday':
../src/gettimeofday.h:39: warning: unused variable `tzflag'
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_open':
../src/SerialImp.c:514: warning: int format, long int arg (arg 4)
../src/SerialImp.c:514: warning: int format, long int arg (arg 5)
../src/SerialImp.c:571: warning: int format, long int arg (arg 2)
../src/SerialImp.c:571: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeClose':
../src/SerialImp.c:597: warning: int format, long int arg (arg 4)
../src/SerialImp.c:597: warning: int format, long int arg (arg 5)
../src/SerialImp.c:634: warning: int format, long int arg (arg 2)
../src/SerialImp.c:634: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function 
`Java_gnu_io_RXTXPort_nativeSetSerialPortParams':
../src/SerialImp.c:768: warning: int format, long int arg (arg 4)
../src/SerialImp.c:768: warning: int format, long int arg (arg 5)
../src/SerialImp.c:797: warning: int format, long int arg (arg 2)
../src/SerialImp.c:797: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `init_threads':
../src/SerialImp.c:1217: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1217: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeByte':
../src/SerialImp.c:1244: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1244: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1283: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_writeArray':
../src/SerialImp.c:1330: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1330: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1385: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain':
../src/SerialImp.c:1414: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1414: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1442: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_sendBreak':
../src/SerialImp.c:1458: warning: int format, long int arg (arg 4)
../src/SerialImp.c:1458: warning: int format, long int arg (arg 5)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 2)
../src/SerialImp.c:1461: warning: int format, long int arg (arg 3)
../src/SerialImp.c: In function `read_byte_array':
../src/SerialImp.c:2794: warning: int format, long int arg (arg 4)
../src/SerialImp.c:2794: warning: int format, long int arg (arg 5)
../src/SerialImp.c: In function `Java_gnu_io_RXTXPort_eventLoop':
../src/SerialImp.c:3919: warning: int format, long int arg (arg 2)
../src/SerialImp.c:3919: warning: int format, long int arg (arg 3)
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/termios.c -o termios.o
gcc -O2 -I . -I /c/j2sdk1.4.1_02-rxtx//include -I 
/c/j2sdk1.4.1_02-rxtx//include/win32 -I "../src" -I include -I 
/c/mingw/include -mno-cygwin -DWIN32 -D __int64="long long" 
-mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D 
DEBUG_TIMING -c "../src"/init.cc -o init.o
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
cp   "../src"/Serial.def gnu/io/
ld --base-file Serial.base --dll -o rxtxSerial.dll fixup.o SerialImp.o 
termios.o init.o \
-L. -L "/c/mingw/lib" -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 
-lmoldname -lcrtdll -lgcc -lmingw32 -e _dll_entry at 12
dlltool --as=as --dllname rxtxSerial.dll --def "../src"/Serial.def \
         --base-file Serial.base --output-exp Serial.exp
ld --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
fixup.o SerialImp.o termios.o init.o -L. -L "/c/mingw/lib" -luser32 -lgdi32 
-lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc -lmingw32 -e 
_dll_entry at 12
Serial.exp(.edata+0xb0):fake: undefined reference to 
`Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12'
make: *** [rxtxSerial.dll] Error 1

I know enough about C and makefiles to get there, but this is kind of out 
of my league. Any idea about ways to solve this problem?

Best Regards,

David Garnier




-------------- next part --------------
#-------------------------------------------------------------------------
#   rxtx is a native interface to serial ports in java.
#   Copyright 1997-2002 by Trent Jarvi taj at www.linux.org.uk.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU Library General Public
#   License as published by the Free Software Foundation; either
#   version 2 of the License, or (at your option) any later version.
#
#   This library is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#   Library General Public License for more details.
#
#   You should have received a copy of the GNU Library General Public
#   License along with this library; if not, write to the Free
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#-------------------------------------------------------------------------
#  This Makefile works on windows 2000 with mingw32 in a minsys shell.
#  One catch.  We cant figure out how to generate .def files with default
#  DOS tools and mingw32.  Install Cygwin if you are adding/removing/chaninging
#  C functions. 
# 
#  The Javax Comm Library must be installed in $COMMINSTALL prior to running this script.
#
#  libgcc.a MUST be in MINGW/lib (it is not by default)


######################
#  user defined variables
######################

# path to the jdk directory that has include, bin, lib, ...
JAVA_HOME=/c/j2sdk1.4.1_02-rxtx/

#path to mingw32
MINGHOME=/c/mingw



######################
#  Variables that you may want to change if you like to mess up with things and stuff.
######################

# path to the source code (directory with SerialImp.c) 
SRC="../src"

# path to install RXTXcomm.jar DOS style path
COMMINSTALL="$(JAVA_HOME)/jre/lib/ext"

# path to install the shared libraries DOS style path
LIBINSTALL="$(JAVA_HOME)/jre/bin"

# path to the mingw32 libraries (directory with libmingw32.a)
LIBDIR="$(MINGHOME)/lib"

######################
#  Tools
######################

AS=as
CC=gcc
LD=ld
DLLTOOL=dlltool
# this looks like a nice tool but I was not able to get symbols in the dll.
DLLWRAP=dllwrap

CLASSPATH=-classpath .:$(COMMINSTALL)/comm.jar
JAVAH=javah $(CLASSPATH)
JAR=jar 
JAVAC=javac $(CLASSPATH)

######################
#  Tool Flags
######################

CFLAGS_CYGWIN= -O2 $(INCLUDE) -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall 
CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387  -Wall -D TRACE -D DEBUG_VERBOSE -D DEBUG -D DEBUG_TIMING
#CFLAGS= -O2 $(INCLUDE) -mno-cygwin -DWIN32 -D __int64="long long" -mno-fp-ret-in-387 -Wall -D TRENT_IS_HERE_DEBUGGING_ENUMERATION -DTRENT_IS_HERE_DEBUGGING_THREADS

INCLUDE= -I . -I $(JDKINCLUDE) -I $(JDKINCLUDE)/win32 -I $(SRC) -I include -I $(MINGINCLUDE)
JAVAHFLAGS= -jni -d include
LIBS=-L. -L $(LIBDIR) -luser32 -lgdi32 -lcomdlg32 -lkernel32 -ladvapi32 -lmoldname -lcrtdll -lgcc

# path to the java native interface headers (directory with jni.h)
JDKINCLUDE=$(JAVA_HOME)/include
MINGINCLUDE=$(MINGHOME)/include
JAVAFILES = $(wildcard $(SRC)/*.java)
CFILES=$(wildcard $(SRC)/*.c) $(wildcard $(SRC)/*.cc)

TARGETLIBS= rxtxSerial.dll 
DLLOBJECTS= fixup.o SerialImp.o termios.o init.o

all:  $(TARGETLIBS) # rebuild  rebuild will force everything to be built.



include:
	mkdir include

gnu:
	mkdir gnu
	mkdir gnu/io

# yayaya We should have put the files in gnu.io to start with
gnutimestamp:	$(JAVAFILES) $(CFILES) include gnu
	cp $(SRC)/*.* gnu/io/
	echo > gnutimestamp

# FIXME make 3.79.1 behaves really strage if we use %.o rules.

init.o:	
	$(CC) $(CFLAGS) -c $(SRC)/init.cc -o init.o

fixup.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o fixup.o

SerialImp.o:  include/config.h
	$(CC) $(CFLAGS) -c $(SRC)/SerialImp.c -o SerialImp.o

termios.o:
	$(CC) $(CFLAGS) -c $(SRC)/$*.c -o termios.o

#  This file is a pain in the rear to generate.  If your looking at this you
#  need to install cygwin.

$(SRC)/Serial.def:	$(DLLOBJECTS)
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	cp   $(SRC)/Serial.def gnu/io/
#	echo EXPORTS >$(SRC)/Serial.def;for i in `nm rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(SRC)/Serial.def

rxtxSerial.dll:	RXTXcomm.jar $(DLLOBJECTS)  $(SRC)/Serial.def
	$(LD) --base-file Serial.base --dll -o rxtxSerial.dll $(DLLOBJECTS) \
		$(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
	$(DLLTOOL) --as=$(AS) --dllname rxtxSerial.dll --def $(SRC)/Serial.def \
		--base-file Serial.base --output-exp Serial.exp
	$(LD) --base-file Serial.base Serial.exp -dll -o rxtxSerial.dll \
		$(DLLOBJECTS) $(LIBS) -lmingw32 -e _dll_entry at 12
#
# This should replace the mess above if it worked.
# nm shows no symbols in the dll produced.  The old stuff above works ok.
#	$(DLLWRAP) --output-def $*.def --output-exp $*.exp \
#		--add-stdcall-alias --driver-name gcc -mwindows \
#		--target=i386-mingw32 -o $*.dll $(DLLOBJECTS) $(LIBS) -s
#		-mno-cygwin


RXTXcomm.jar:	gnutimestamp
	$(JAVAC) gnu/io/*.java
	$(JAR) -cf RXTXcomm.jar gnu/io/*.class
	$(JAVAH) $(JAVAHFLAGS) $(patsubst gnu/io/%.java,gnu.io.%,$(wildcard gnu/io/*.java))

include/config.h:  gnutimestamp
	echo "#define HAVE_FCNTL_H 1" > include/config.h
	echo "#define HAVE_SIGNAL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FCNTL_H 1" >> include/config.h
	echo "#define HAVE_SYS_FILE_H 1" >> include/config.h
	echo "#undef HAVE_SYS_SIGNAL_H" >> include/config.h
	echo "#undef HAVE_TERMIOS_H" >> include/config.h

install: all
	cp RXTXcomm.jar $(COMMINSTALL)
	cp $(TARGETLIBS) $(LIBINSTALL)

#uninstall:
#	del $(COMMINSTALL)\\\RXTXcomm.jar
#	del $(LIBINSTALL)\\\$(TARGETLIBS)

clean:
	rm -rf gnu include RXTXcomm.jar Serial.* rxtxSerial.* *.O.o *.O *.o gnutimestamp 

From edpersson at qwest.net  Thu Nov  6 08:25:39 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 08:25:39 -0700
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx.
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well.
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment!
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
drain_loop:  writing not set
drain_loop:  looping
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
Bus error

The debug information from OSX is:
Date/Time:  2003-11-05 13:12:50 -0700
OS Version: 10.3 (Build 7B85)

Command:    java (/usr/bin/java)
PID:        5232
Thread:     1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000004

Thread 0:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
848)
  #3   0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #4   0x927d5ecc in RunCurrentEventLoopInMode
(RunCurrentEventLoopInMode + 172)
  #5   0x927dc640 in ReceiveNextEventCommon
(ReceiveNextEventCommon + 380)
  #6   0x927fe6d0 in
BlockUntilNextEventMatchingListInMode
(BlockUntilNextEventMatchingListInMode + 96)
  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
384)
  #8   0x92de93fc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
(-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
116)
  #9   0x92dfd730 in -[NSApplication run]
(-[NSApplication run] + 540)
  #10  0x817db7c4 in -[StartupUtility run]
(-[StartupUtility run] + 272)
  #11  0x90a1ad24 in __NSFireMainThreadPerform
(__NSFireMainThreadPerform + 264)
  #12  0x901e4820 in __CFRunLoopPerformPerform
(__CFRunLoopPerformPerform + 136)
  #13  0x90193ed8 in __CFRunLoopDoSources0
(__CFRunLoopDoSources0 + 508)
  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
432)
  #15  0x901960bc in CFRunLoopRunSpecific
(CFRunLoopRunSpecific + 328)
  #16  0x000061d8 in 0x61d8
  #17  0x00003c88 in 0x3c88
  #18  0x00003afc in 0x3afc

Thread 1 Crashed:
  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
892)
  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
(JVM_GetCPFieldClassNameUTF + 15932)
  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
(JVM_GetMethodIxLocalsCount + 10736)
  #3   0x947fd8e0 in JVM_SocketAvailable
(JVM_SocketAvailable + 4544)
  #4   0x947d5654 in JVM_FillInStackTrace
(JVM_FillInStackTrace + 4356)
  #5   0x947abb80 in JVM_MonitorNotify
(JVM_MonitorNotify + 1984)
  #6   0x03da6568 in 0x3da6568
  #7   0x03d9516c in 0x3d9516c
  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #9   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #10  0x948d2cf0 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72080)
  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
1176)
  #12  0x0895d0f8 in send_event (send_event + 204)
  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
(Java_gnu_io_RXTXPort_nativeDrain + 300)
  #14  0x03d9e580 in 0x3d9e580
  #15  0x03d97e30 in 0x3d97e30
  #16  0x03d97fb0 in 0x3d97fb0
  #17  0x03d97e30 in 0x3d97e30
  #18  0x03d97fb0 in 0x3d97fb0
  #19  0x03d97e30 in 0x3d97e30
  #20  0x03d98190 in 0x3d98190
  #21  0x03d97ec0 in 0x3d97ec0
  #22  0x03d97fb0 in 0x3d97fb0
  #23  0x03d9516c in 0x3d9516c
  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #25  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #26  0x948d06fc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 62364)
  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
66524)
  #28  0x00004614 in 0x4614
  #29  0x000060c4 in 0x60c4
  #30  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x9487f80c in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17580)
  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
(JNI_CreateJavaVM_Impl + 17472)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
  #4   0x947f0480 in JVM_GetMethodIxModifiers
(JVM_GetMethodIxModifiers + 1264)
  #5   0x94897b8c in JVM_GetInterfaceVersion
(JVM_GetInterfaceVersion + 97052)
  #6   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #7   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 4:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d9516c in 0x3d9516c
  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #11  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #14  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #15  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #16  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #17  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 5:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 6:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7688 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4584)
  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6160)
  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
(JVM_GetCPMethodSignatureUTF + 6576)
  #5   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #6   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 7:
  #0   0x90014628 in semaphore_wait_trap
(semaphore_wait_trap + 8)
  #1   0x948d2e80 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 72480)
  #2   0x948d2044 in JVM_UnloadLibrary
(JVM_UnloadLibrary + 68836)
  #3   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #4   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #5   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 8:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
  #4   0x94811ce0 in JVM_GetFieldIxModifiers
(JVM_GetFieldIxModifiers + 2912)
  #5   0x947fda2c in JVM_SocketAvailable
(JVM_SocketAvailable + 4876)
  #6   0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #7   0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #8   0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 9:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d98310 in 0x3d98310
  #10  0x03d9516c in 0x3d9516c
  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #12  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #15  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #16  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #17  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #18  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 10:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97fb0 in 0x3d97fb0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d97e30 in 0x3d97e30
  #11  0x03d97fb0 in 0x3d97fb0
  #12  0x03d97fb0 in 0x3d97fb0
  #13  0x03d97fb0 in 0x3d97fb0
  #14  0x03d9516c in 0x3d9516c
  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #16  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #19  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #20  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #21  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #22  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 11:
  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
  #1   0x90007118 in mach_msg (mach_msg + 56)
  #2   0x947a7608 in JVM_GetClassAccessFlags
(JVM_GetClassAccessFlags + 4456)
  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
+ 8244)
  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
264)
  #6   0x03d9e580 in 0x3d9e580
  #7   0x03d97fb0 in 0x3d97fb0
  #8   0x03d97ec0 in 0x3d97ec0
  #9   0x03d97ec0 in 0x3d97ec0
  #10  0x03d98310 in 0x3d98310
  #11  0x03d9516c in 0x3d9516c
  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #13  0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #16  0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #17  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #18  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #19  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 12:
  #0   0x9000b30c in select (select + 12)
  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
(Java_gnu_io_RXTXPort_eventLoop + 184)
  #2   0x03d9e580 in 0x3d9e580
  #3   0x03d97fb0 in 0x3d97fb0
  #4   0x03d9516c in 0x3d9516c
  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
(JVM_GetCPMethodClassNameUTF + 2856)
  #6   0x947dbce8 in JVM_GetCPClassNameUTF
(JVM_GetCPClassNameUTF + 2456)
  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
736)
  #9   0x948cdeac in JVM_UnloadLibrary
(JVM_UnloadLibrary + 52044)
  #10  0x948145d4 in JVM_FindClassFromClass
(JVM_FindClassFromClass + 3092)
  #11  0x9496f9cc in JVM_UnloadLibrary
(JVM_UnloadLibrary + 714348)
  #12  0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 13:
  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
+ 8)
  #1   0x9000d858 in nanosleep (nanosleep + 120)
  #2   0x90012388 in usleep (usleep + 72)
  #3   0x08959864 in drain_loop (drain_loop + 60)
  #4   0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
   srr0: 0x947bdd4c srr1: 0x0000f030
vrsave: 0x00000000
     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
ctr: 0x949dcb90
     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
r3: 0x6b0274d0
     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
r7: 0x947bb754
     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
r11: 0x03d9e564
    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
r15: 0x08959d6c
    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
r19: 0xf07ff784
    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
r23: 0xf07ff6d0
    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
r27: 0xf07ff5d4
    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
r31: 0x947bdd3c


Thanks.

edpersson at yahoo.com




From dmarkman at mac.com  Thu Nov  6 09:37:15 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 11:37:15 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C@mac.com>

Hmm,
I didn't change even a byte in PB project from 2.1.7 package
I opened it with XCode 1.0.1 and it built everything out of the box
why did you add -dynamiclib flag?

librxtxSerial.jnilib is building as Mach-O bundle

I don't think it will change anything but still

unfortunately I don't have any hardware right now

so I can't check it




On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From dmarkman at mac.com  Thu Nov  6 10:51:00 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 12:51:00 -0500
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
In-Reply-To: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
References: <7A03CAEE-106D-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C87E0588-1081-11D8-83D1-000A95DA5E9C@mac.com>

BTW: did you install latest KeySpan drivers for Panther?
(if you use KeySpan adapter of course)

On Nov 6, 2003, at 10:25 AM, Erik Persson wrote:

> Greetings,
>
> I have downloaded, compiled and installed both
> rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.
>
> In both cases I used the pbproject with XCode.  The
> only change I had to make was the addition of a Mach-O
> Linker flag of "-dynamiclib".
>
> After doing some very simple verifications using
> contrib/Test.java, I compiled and tried to use the
> Dallas Semicondutor iButton software which uses rxtx.
> After a quick change to the imports (gnu.io) and a few
> changes for JDK1.4 support, I thought I was ready to
> go.
>
> A quick "Bus error" indicated that all was not well.
> After digging around a bit, I have found the
> following, perhaps meaningful error information.
>
> If there is an rxtx test suite that I should run or
> any other debugging that would help, I am happy to do
> so.
>
> It may well be that this bug is in Panther and not
> RXTX, but I figured I would start here since I suspect
> that Apple developers are a bit busy at the moment!
> ;-)  My apologies in advance if this post is
> off-topic, does not provide enough detail, should have
> waited for me to do more debugging, or is just too
> boring for this list.
>
> The java code in question is trying to flush on a
> SerialPort's output stream when the kernel exception
> occurs.
>
> With DEBUG and DEBUG_VERBOSE defined for the RXTX
> jnilibs I get the following output (the first line
> coming from the dalsemi java code):
>
> DEBUG: USerialAdapter-flush
> W(c1)writeByte ?>>
> writeByte:  index->writing = 1RXTXPort:writeByte 1
> nativeDrain: trying tcdrain
> RXTXPort:drain() returns: 0
> send_event: !eventloop_interupted
> send_event: jclazz
> send_event: calling
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> drain_loop:  writing not set
> drain_loop:  looping
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> entering check_tiocmget_changes
> leaving check_tiocmget_changes
> port_has_changed_fionread: change is 0
> Bus error
>
> The debug information from OSX is:
> Date/Time:  2003-11-05 13:12:50 -0700
> OS Version: 10.3 (Build 7B85)
>
> Command:    java (/usr/bin/java)
> PID:        5232
> Thread:     1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at
> 0x00000004
>
> Thread 0:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x90191930 in __CFRunLoopRun (__CFRunLoopRun +
> 848)
>  #3   0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #4   0x927d5ecc in RunCurrentEventLoopInMode
> (RunCurrentEventLoopInMode + 172)
>  #5   0x927dc640 in ReceiveNextEventCommon
> (ReceiveNextEventCommon + 380)
>  #6   0x927fe6d0 in
> BlockUntilNextEventMatchingListInMode
> (BlockUntilNextEventMatchingListInMode + 96)
>  #7   0x92dd2a80 in _DPSNextEvent (_DPSNextEvent +
> 384)
>  #8   0x92de93fc in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> (-[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] +
> 116)
>  #9   0x92dfd730 in -[NSApplication run]
> (-[NSApplication run] + 540)
>  #10  0x817db7c4 in -[StartupUtility run]
> (-[StartupUtility run] + 272)
>  #11  0x90a1ad24 in __NSFireMainThreadPerform
> (__NSFireMainThreadPerform + 264)
>  #12  0x901e4820 in __CFRunLoopPerformPerform
> (__CFRunLoopPerformPerform + 136)
>  #13  0x90193ed8 in __CFRunLoopDoSources0
> (__CFRunLoopDoSources0 + 508)
>  #14  0x90191790 in __CFRunLoopRun (__CFRunLoopRun +
> 432)
>  #15  0x901960bc in CFRunLoopRunSpecific
> (CFRunLoopRunSpecific + 328)
>  #16  0x000061d8 in 0x61d8
>  #17  0x00003c88 in 0x3c88
>  #18  0x00003afc in 0x3afc
>
> Thread 1 Crashed:
>  #0   0x947bdd4c in JVM_ReleaseUTF (JVM_ReleaseUTF +
> 892)
>  #1   0x947c310c in JVM_GetCPFieldClassNameUTF
> (JVM_GetCPFieldClassNameUTF + 15932)
>  #2   0x947c6f70 in JVM_GetMethodIxLocalsCount
> (JVM_GetMethodIxLocalsCount + 10736)
>  #3   0x947fd8e0 in JVM_SocketAvailable
> (JVM_SocketAvailable + 4544)
>  #4   0x947d5654 in JVM_FillInStackTrace
> (JVM_FillInStackTrace + 4356)
>  #5   0x947abb80 in JVM_MonitorNotify
> (JVM_MonitorNotify + 1984)
>  #6   0x03da6568 in 0x3da6568
>  #7   0x03d9516c in 0x3d9516c
>  #8   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #9   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #10  0x948d2cf0 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72080)
>  #11  0x9498e858 in jio_vsnprintf (jio_vsnprintf +
> 1176)
>  #12  0x0895d0f8 in send_event (send_event + 204)
>  #13  0x08959e98 in Java_gnu_io_RXTXPort_nativeDrain
> (Java_gnu_io_RXTXPort_nativeDrain + 300)
>  #14  0x03d9e580 in 0x3d9e580
>  #15  0x03d97e30 in 0x3d97e30
>  #16  0x03d97fb0 in 0x3d97fb0
>  #17  0x03d97e30 in 0x3d97e30
>  #18  0x03d97fb0 in 0x3d97fb0
>  #19  0x03d97e30 in 0x3d97e30
>  #20  0x03d98190 in 0x3d98190
>  #21  0x03d97ec0 in 0x3d97ec0
>  #22  0x03d97fb0 in 0x3d97fb0
>  #23  0x03d9516c in 0x3d9516c
>  #24  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #25  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #26  0x948d06fc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 62364)
>  #27  0x9499e79c in jio_vsnprintf (jio_vsnprintf +
> 66524)
>  #28  0x00004614 in 0x4614
>  #29  0x000060c4 in 0x60c4
>  #30  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 2:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x9487f80c in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17580)
>  #3   0x9487f7a0 in JNI_CreateJavaVM_Impl
> (JNI_CreateJavaVM_Impl + 17472)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 3:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947da944 in __divdi3 (__divdi3 + 20612)
>  #4   0x947f0480 in JVM_GetMethodIxModifiers
> (JVM_GetMethodIxModifiers + 1264)
>  #5   0x94897b8c in JVM_GetInterfaceVersion
> (JVM_GetInterfaceVersion + 97052)
>  #6   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #7   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 4:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d9516c in 0x3d9516c
>  #10  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #11  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #12  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #13  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #14  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #15  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #16  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #17  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 5:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 6:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7688 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4584)
>  #3   0x947b7130 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6160)
>  #4   0x947b72d0 in JVM_GetCPMethodSignatureUTF
> (JVM_GetCPMethodSignatureUTF + 6576)
>  #5   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #6   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 7:
>  #0   0x90014628 in semaphore_wait_trap
> (semaphore_wait_trap + 8)
>  #1   0x948d2e80 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 72480)
>  #2   0x948d2044 in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 68836)
>  #3   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #4   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #5   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 8:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947da9a4 in __divdi3 (__divdi3 + 20708)
>  #4   0x94811ce0 in JVM_GetFieldIxModifiers
> (JVM_GetFieldIxModifiers + 2912)
>  #5   0x947fda2c in JVM_SocketAvailable
> (JVM_SocketAvailable + 4876)
>  #6   0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #7   0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #8   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 9:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d98310 in 0x3d98310
>  #10  0x03d9516c in 0x3d9516c
>  #11  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #12  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #13  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #14  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #15  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #16  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #17  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #18  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 10:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97fb0 in 0x3d97fb0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d97e30 in 0x3d97e30
>  #11  0x03d97fb0 in 0x3d97fb0
>  #12  0x03d97fb0 in 0x3d97fb0
>  #13  0x03d97fb0 in 0x3d97fb0
>  #14  0x03d9516c in 0x3d9516c
>  #15  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #16  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #17  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #18  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #19  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #20  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #21  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #22  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 11:
>  #0   0x900075c8 in mach_msg_trap (mach_msg_trap + 8)
>  #1   0x90007118 in mach_msg (mach_msg + 56)
>  #2   0x947a7608 in JVM_GetClassAccessFlags
> (JVM_GetClassAccessFlags + 4456)
>  #3   0x947a2034 in _mh_dylib_header (_mh_dylib_header
> + 8244)
>  #4   0x947ab3a4 in __cmpdi2 (__cmpdi2 + 6820)
>  #5   0x947a7ae8 in JVM_MonitorWait (JVM_MonitorWait +
> 264)
>  #6   0x03d9e580 in 0x3d9e580
>  #7   0x03d97fb0 in 0x3d97fb0
>  #8   0x03d97ec0 in 0x3d97ec0
>  #9   0x03d97ec0 in 0x3d97ec0
>  #10  0x03d98310 in 0x3d98310
>  #11  0x03d9516c in 0x3d9516c
>  #12  0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #13  0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #14  0x94818868 in JVM_Close (JVM_Close + 1208)
>  #15  0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #16  0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #17  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #18  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #19  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 12:
>  #0   0x9000b30c in select (select + 12)
>  #1   0x0895c598 in Java_gnu_io_RXTXPort_eventLoop
> (Java_gnu_io_RXTXPort_eventLoop + 184)
>  #2   0x03d9e580 in 0x3d9e580
>  #3   0x03d97fb0 in 0x3d97fb0
>  #4   0x03d9516c in 0x3d9516c
>  #5   0x947ba0f8 in JVM_GetCPMethodClassNameUTF
> (JVM_GetCPMethodClassNameUTF + 2856)
>  #6   0x947dbce8 in JVM_GetCPClassNameUTF
> (JVM_GetCPClassNameUTF + 2456)
>  #7   0x94818868 in JVM_Close (JVM_Close + 1208)
>  #8   0x94829120 in JVM_Interrupt (JVM_Interrupt +
> 736)
>  #9   0x948cdeac in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 52044)
>  #10  0x948145d4 in JVM_FindClassFromClass
> (JVM_FindClassFromClass + 3092)
>  #11  0x9496f9cc in JVM_UnloadLibrary
> (JVM_UnloadLibrary + 714348)
>  #12  0x900247e8 in _pthread_body (_pthread_body + 40)
>
> Thread 13:
>  #0   0x90012688 in clock_sleep_trap (clock_sleep_trap
> + 8)
>  #1   0x9000d858 in nanosleep (nanosleep + 120)
>  #2   0x90012388 in usleep (usleep + 72)
>  #3   0x08959864 in drain_loop (drain_loop + 60)
>  #4   0x900247e8 in _pthread_body (_pthread_body + 40)
>
> PPC Thread State:
>   srr0: 0x947bdd4c srr1: 0x0000f030
> vrsave: 0x00000000
>     cr: 0x82002224  xer: 0x20000004   lr: 0x947bdd3c
> ctr: 0x949dcb90
>     r0: 0x6b0274e8   r1: 0xf07ff3a0   r2: 0x02816430
> r3: 0x6b0274d0
>     r4: 0x00000000   r5: 0x005125b0   r6: 0x82002224
> r7: 0x947bb754
>     r8: 0x00003000   r9: 0x0281642c  r10: 0x947fd8e0
> r11: 0x03d9e564
>    r12: 0x949dcb90  r13: 0x005125b0  r14: 0x670659d8
> r15: 0x08959d6c
>    r16: 0xf07ff7a0  r17: 0x6b02c870  r18: 0xf07ff834
> r19: 0xf07ff784
>    r20: 0x6b0341f0  r21: 0x6b02c753  r22: 0x03d9e580
> r23: 0xf07ff6d0
>    r24: 0x005125b0  r25: 0x00000000  r26: 0x00000000
> r27: 0xf07ff5d4
>    r28: 0x0281642c  r29: 0x00000000  r30: 0x6b0274d0
> r31: 0x947bdd3c
>
>
> Thanks.
>
> edpersson at yahoo.com
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 11:14:09 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 11:14:09 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <20031106163003.DA07173298@mail.linuxgrrls.org>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
Message-ID: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

I am embarrassed to say that I cannot reproduce the linker problem with 
a fresh version of:
ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
I guess I was not as methodical as I had thought.  Sorry.

Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
was:
"-single_module or -multi_module flags can only be used when -dylib is 
also specified"

After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
there was one small problem, which is that  "RXTXcomm" target does not 
have Zystem.java or UnSupportedLoggerException.java, so I added those 
from the src directory.  Clearly not a big deal.

Sadly I still get the bus error with the "-bundle" version of 
2.1-7pre16.  I verified that I am using the jnilib and jar files that I 
just built above.

Unless someone can point out some existing test code for rxtx (or any 
other test which should be run), I will try to simplify the code 
required to reproduce the "Bus error."

Thanks,
Erik


> Message: 2
> Date: Thu, 6 Nov 2003 11:37:15 -0500
> From: Dmitry Markman <dmarkman at mac.com>
> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
> To: Java RXTX discussion <rxtx at linuxgrrls.org>
> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hmm,
> I didn't change even a byte in PB project from 2.1.7 package
> I opened it with XCode 1.0.1 and it built everything out of the box
> why did you add -dynamiclib flag?
>
> librxtxSerial.jnilib is building as Mach-O bundle
>
> I don't think it will change anything but still
>
> unfortunately I don't have any hardware right now
>
> so I can't check it
>
...

> Dmitry Markman
>
>
> ------------------------------
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
> End of Rxtx Digest, Vol 8, Issue 2
> **********************************
>



From dmarkman at mac.com  Thu Nov  6 12:24:03 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 14:24:03 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 2
In-Reply-To: <044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106163003.DA07173298@mail.linuxgrrls.org>
	<044E778A-1085-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <C7C78AC4-108E-11D8-8228-000A95DA5E9C@mac.com>

I tried 2.1.7 package with our application
and it worked for about 3-4 min without problem
after that I just quit
and I saw that lock file was deleted properly

I'm working with 10.3 jdk 1.4.1

but maybe you have other hardware

our use communication with communication with low rate


I tested contrib/Test.java as well

only change I did:

I put 		TxPort.initialize();
after creating TxPort
otherwise I got nullPointer exception (osName wasn't defined)

and I put System.exit(0) at very end (otherwise JVM didn't quit)

after that I tried with 2 available ports:


java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
opening the Port: /dev/tty.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent

and


java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
opening the Port: /dev/cu.USA19QW3b1P1.1
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
open Ports
RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
Get Streams
Baud is 9600
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 19200
Bits is 8
Stop is 1
Par is 0
Set Params
Baud is 9600
Bits is 7
Stop is 2
Par is 1
Sending 0x01
0x01 Sent


no exception no bus error

nothing :-(



On Nov 6, 2003, at 1:14 PM, Erik Persson wrote:

> Dmitry,
>
> I am embarrassed to say that I cannot reproduce the linker problem 
> with a fresh version of:
> ftp://jarvi.dsl.frii.com/pub/rxtx-2.1-7pre16.tar.gz
> I guess I was not as methodical as I had thought.  Sorry.
>
> Just for reference, the error I 'fixed' with "-dynamiclib" for 2.1-6 
> was:
> "-single_module or -multi_module flags can only be used when -dylib is 
> also specified"
>
> After unpacking rxtx-2.1-7pre16/MACOSX_IDE/PB/LibSerial.pbproj.sit.hqx 
> there was one small problem, which is that  "RXTXcomm" target does not 
> have Zystem.java or UnSupportedLoggerException.java, so I added those 
> from the src directory.  Clearly not a big deal.
>
> Sadly I still get the bus error with the "-bundle" version of 
> 2.1-7pre16.  I verified that I am using the jnilib and jar files that 
> I just built above.
>
> Unless someone can point out some existing test code for rxtx (or any 
> other test which should be run), I will try to simplify the code 
> required to reproduce the "Bus error."
>
> Thanks,
> Erik
>
>
>> Message: 2
>> Date: Thu, 6 Nov 2003 11:37:15 -0500
>> From: Dmitry Markman <dmarkman at mac.com>
>> Subject: Re: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
>> To: Java RXTX discussion <rxtx at linuxgrrls.org>
>> Message-ID: <7A928A2E-1077-11D8-99CF-000A95DA5E9C at mac.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hmm,
>> I didn't change even a byte in PB project from 2.1.7 package
>> I opened it with XCode 1.0.1 and it built everything out of the box
>> why did you add -dynamiclib flag?
>>
>> librxtxSerial.jnilib is building as Mach-O bundle
>>
>> I don't think it will change anything but still
>>
>> unfortunately I don't have any hardware right now
>>
>> so I can't check it
>>
> ...
>
>> Dmitry Markman
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at linuxgrrls.org
>> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>>
>>
>> End of Rxtx Digest, Vol 8, Issue 2
>> **********************************
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From edpersson at qwest.net  Thu Nov  6 13:08:10 2003
From: edpersson at qwest.net (Erik Persson)
Date: Thu, 6 Nov 2003 13:08:10 -0700
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <20031106191650.C27D873601@mail.linuxgrrls.org>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
Message-ID: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>

Dmitry,

It looks like I am wasting peoples time on the rxtx list.  I just had 
another java app (jEdit, with no serial port code at all) crash with a 
very similar stack trace.  Though I might continue to see if I can come 
up with a more specific way to reproduce the crash, I am currently 
thinking that this is a 10.3/java problem and not an rxtx problem.

Thanks for your help.  I will post to this list if I figure anything 
out.

Misc comments regarding your last post, made before I observed the very 
similar crash in another java app:
As I mentioned in my first email, I had (and have) no problems running 
contrib/Test.

The test runs fine (with the changes you describe) on both 
/dev/tty.modem and /dev/tty.USA19QW812P1.1.
I do have the latest Keyspan drivers installed.

I did not see the problem until using a package from Dallas 
Semiconductor for their iButton products.  Using their package I see 
the bus error regardless of which serial port is being accessed.

-Erik

> I tried 2.1.7 package with our application
> and it worked for about 3-4 min without problem
> after that I just quit
> and I saw that lock file was deleted properly
>
> I'm working with 10.3 jdk 1.4.1
>
> but maybe you have other hardware
>
> our use communication with communication with low rate
>
>
> I tested contrib/Test.java as well
>
> only change I did:
>
> I put 		TxPort.initialize();
> after creating TxPort
> otherwise I got nullPointer exception (osName wasn't defined)
>
> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>
> after that I tried with 2 available ports:
>
>
> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
> opening the Port: /dev/tty.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.012
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
> and
>
>
> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
> opening the Port: /dev/cu.USA19QW3b1P1.1
> Devel Library
> =========================================
> Native lib Version = RXTX-2.1-7pre17
> Java lib Version   = RXTX-2.1-7pre17
> open Ports
> RXTX Warning:  Removing stale lock file. /var/spool/uucp/LK.001.008.013
> Get Streams
> Baud is 9600
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 19200
> Bits is 8
> Stop is 1
> Par is 0
> Set Params
> Baud is 9600
> Bits is 7
> Stop is 2
> Par is 1
> Sending 0x01
> 0x01 Sent
>
>
> no exception no bus error
>
> nothing :-(
>
>



From dmarkman at mac.com  Thu Nov  6 14:11:50 2003
From: dmarkman at mac.com (Dmitry Markman)
Date: Thu, 6 Nov 2003 16:11:50 -0500
Subject: [Rxtx] Re: Rxtx Digest, Vol 8, Issue 3
In-Reply-To: <F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
References: <20031106191650.C27D873601@mail.linuxgrrls.org>
	<F208C933-1094-11D8-BDAC-003065BF1AB2@qwest.net>
Message-ID: <D6E1CD2D-109D-11D8-8228-000A95DA5E9C@mac.com>

BTW

can you send me output of java -version
command

you can do that off-list if you like


On Nov 6, 2003, at 3:08 PM, Erik Persson wrote:

> Dmitry,
>
> It looks like I am wasting peoples time on the rxtx list.  I just had 
> another java app (jEdit, with no serial port code at all) crash with a 
> very similar stack trace.  Though I might continue to see if I can 
> come up with a more specific way to reproduce the crash, I am 
> currently thinking that this is a 10.3/java problem and not an rxtx 
> problem.
>
> Thanks for your help.  I will post to this list if I figure anything 
> out.
>
> Misc comments regarding your last post, made before I observed the 
> very similar crash in another java app:
> As I mentioned in my first email, I had (and have) no problems running 
> contrib/Test.
>
> The test runs fine (with the changes you describe) on both 
> /dev/tty.modem and /dev/tty.USA19QW812P1.1.
> I do have the latest Keyspan drivers installed.
>
> I did not see the problem until using a package from Dallas 
> Semiconductor for their iButton products.  Using their package I see 
> the bus error regardless of which serial port is being accessed.
>
> -Erik
>
>> I tried 2.1.7 package with our application
>> and it worked for about 3-4 min without problem
>> after that I just quit
>> and I saw that lock file was deleted properly
>>
>> I'm working with 10.3 jdk 1.4.1
>>
>> but maybe you have other hardware
>>
>> our use communication with communication with low rate
>>
>>
>> I tested contrib/Test.java as well
>>
>> only change I did:
>>
>> I put 		TxPort.initialize();
>> after creating TxPort
>> otherwise I got nullPointer exception (osName wasn't defined)
>>
>> and I put System.exit(0) at very end (otherwise JVM didn't quit)
>>
>> after that I tried with 2 available ports:
>>
>>
>> java -jar ContribTest.jar /dev/tty.USA19QW3b1P1.1
>> opening the Port: /dev/tty.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.012
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>> and
>>
>>
>> java -jar ContribTest.jar /dev/cu.USA19QW3b1P1.1
>> opening the Port: /dev/cu.USA19QW3b1P1.1
>> Devel Library
>> =========================================
>> Native lib Version = RXTX-2.1-7pre17
>> Java lib Version   = RXTX-2.1-7pre17
>> open Ports
>> RXTX Warning:  Removing stale lock file. 
>> /var/spool/uucp/LK.001.008.013
>> Get Streams
>> Baud is 9600
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 19200
>> Bits is 8
>> Stop is 1
>> Par is 0
>> Set Params
>> Baud is 9600
>> Bits is 7
>> Stop is 2
>> Par is 1
>> Sending 0x01
>> 0x01 Sent
>>
>>
>> no exception no bus error
>>
>> nothing :-(
>>
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at linuxgrrls.org
> http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
>
>
Dmitry Markman



From david.garnier at trusted-logic.fr  Fri Nov  7 08:07:23 2003
From: david.garnier at trusted-logic.fr (David Garnier)
Date: Fri, 07 Nov 2003 16:07:23 +0100
Subject: [Rxtx] Still trying to run Rxtx under Windows
Message-ID: <5.2.0.9.0.20031107151826.02b505c8@mail.trusted-logic.fr>

Hello,

I finally managed to compile the rxtx dll under Windows, but it doesn't 
work. I can load it in the JVM, open the port and talk to it, but I'm not 
getting anything back. I'm using this short snippet to open the port:


    public static void main(String[] args) throws IOException
    {
       CommPortIdentifier portId = null;
       try
       {
          portId = CommPortIdentifier.getPortIdentifier("COM1");
          SerialPort serialPort = (SerialPort) portId.open("Trusted Logic 
libcad", 2000);

          //  serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_2, SerialPort.PARITY_EVEN);
          OutputStream os = serialPort.getOutputStream();
          os.write(1);
          os.flush();
          InputStream is = serialPort.getInputStream();
          int val =is.read();
          System.out.println("Read:" + val);

       } catch (PortInUseException e)
       {
          throw new CADException("Port COM1 is already used.");
       } catch (NoSuchPortException e)
       {
          e.printStackTrace();
       }
    }

In order to see what's going on, I have attached a monitor to the serial 
port. The log files for Javax.Comm and RXTX are attached. It seems to me 
that RXTX does not actually tries to read data, but I don't know if this is 
really the problem.

Best Regards,
David Garnier






-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open 	
IOCTL_SERIAL_SET_QUEUE_SIZE	Serial2	SUCCESS	InSize: 2048 OutSize: 1024	
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:0 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_TIMEOUTS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_CLR_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:0 XonLimit:0 XoffLimit:0	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IRP_MJ_FLUSH_BUFFERS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: TXEMPTY 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 0: 	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
# Numerous GET_MODEMSTATUS  and GET_COMMSTATUS calls...*/
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		
-------------- next part --------------
IRP_MJ_CREATE	Serial2	SUCCESS	Options: Open NoBuffer	
IOCTL_SERIAL_SET_TIMEOUTS	Serial2	SUCCESS	RI:-1 RM:0 RC:0 WM:0 WC:0	
IOCTL_SERIAL_SET_WAIT_MASK	Serial2	SUCCESS	Mask: RXCHAR ERR 	
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_MODEMSTATUS	Serial2	SUCCESS		
IOCTL_SERIAL_CONFIG_SIZE	Serial2	SUCCESS	Size: 0	
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_GET_PROPERTIES	Serial2	SUCCESS		
IOCTL_SERIAL_GET_BAUD_RATE	Serial2	SUCCESS		
IOCTL_SERIAL_GET_LINE_CONTROL	Serial2	SUCCESS		
IOCTL_SERIAL_GET_CHARS	Serial2	SUCCESS		
IOCTL_SERIAL_GET_HANDFLOW	Serial2	SUCCESS		
IOCTL_SERIAL_SET_BAUD_RATE	Serial2	SUCCESS	Rate: 9600	
IOCTL_SERIAL_SET_RTS	Serial2	SUCCESS		
IOCTL_SERIAL_SET_DTR	Serial2	SUCCESS		
IOCTL_SERIAL_SET_LINE_CONTROL	Serial2	SUCCESS	StopBits: 1 Parity: NONE WordLength: 8	
IOCTL_SERIAL_SET_CHAR	Serial2	SUCCESS	EOF:4 ERR:0 BRK:0 EVT:a XON:11 XOFF:13	
IOCTL_SERIAL_SET_HANDFLOW	Serial2	SUCCESS	Shake:1 Replace:40 XonLimit:16 XoffLimit:1024	
IRP_MJ_WRITE	Serial2	SUCCESS	Length 1: .	
IOCTL_SERIAL_GET_COMMSTATUS	Serial2	SUCCESS		
IRP_MJ_READ	Serial2	SUCCESS	Length 1: .	
IRP_MJ_CLEANUP	Serial2	SUCCESS		
IRP_MJ_CLOSE	Serial2	SUCCESS		

From edpersson at qwest.net  Fri Nov  7 14:54:56 2003
From: edpersson at qwest.net (Erik Persson)
Date: Fri, 7 Nov 2003 14:54:56 -0700
Subject: [Rxtx] More on rxtx-2.1-6 & -7, OS X 10.3 (Panther), "Bus Error"
Message-ID: <0646984F-116D-11D8-9AD2-003065BF1AB2@qwest.net>

Hi All,

After looking into it off list with Dmitry, I have some more details 
regarding the problem I described earlier.  After looking into it, I am 
not sure if it is an OS X specific problem or not.

The attached file is a fairly simple demonstration that I built up 
starting with contrib/Test.java.  I am using 2.1-7pre16.

I still don't have a cause identified, but the problem seems related to 
SerialPortEventListener.  In particular, registering with 
notifyOnOutputEmpty.

The attached file is not cleaned up, but the crash should stop when 
commenting out line 76 where notifyOnOutputEmpty is invoked.

After registering for notifyOnOutputEmpty, a call to flush on the 
output stream is enough to cause the problem.

When I enable debugging in RXTXPort, the problem is no longer fatal, 
but ends up looping forever.

Here we are entering the drain code:
   nativeDrain: trying tcdrain
   RXTXPort:drain() returns: 0
   send_event: !eventloop_interupted
   send_event: jclazz
   send_event: calling

Then the following three lines repeat forever:
   entering check_tiocmget_changes
   leaving check_tiocmget_changes
   port_has_changed_fionread: change is 0

Occasionally I see:
   drain_loop:  writing not set
   drain_loop:  looping

Right now I am trying to get gdb to provide more insight into what is 
going on in the jni layer, but I haven't made much progress.

Reading through SerialImp.c and looking at the output seems to indicate 
that we are getting stuck in the RXTXPort.eventLoop native code.  This 
code loops forever, waiting to break.  Part of the event handling code 
in this loop calls port_has_changed_fionread.  It I am reading that 
function correctly, the true or false return value is based on the last 
parameter passed to ioctl.  From the log output above we can see that 
this value is always 0 (false), so we never call send_event in 
eventLoop.  So we go forever.

Assuming that my analysis is correct (always a dangerous assumption ;-) 
), does anyone have any insight into port_has_changed_fionread? and the 
associated ioctl call?

I am happy to run tests if anyone has suggestions.

Thanks,
Erik


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCrash.java
Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20031107/d1e35b67/TestCrash-0004.pl
-------------- next part --------------



From p_narayanamurthy at yahoo.com  Fri Nov  7 23:38:51 2003
From: p_narayanamurthy at yahoo.com (pedapudi narayana murthy)
Date: Fri, 7 Nov 2003 22:38:51 -0800 (PST)
Subject: [Rxtx] MAC Related Issue
Message-ID: <20031108063851.27480.qmail@web40912.mail.yahoo.com>

HI,
Can U Please Let Me know this MAC Related Issues...


1) Can U Please suggest MAC compatiable database like
Microsoft access in windows.Please don't suggest MySQL
as we are developing a stand alone application in java
on MAC(Database at free of cost).


2)Can u suggest Installation shield for MAC
standalone(as Insttallation Sheid for
windows)(Installation Shiled at free of cost).

Thanks and Regards

Narayana

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


From taj at linuxgrrls.org  Sun Nov  9 10:07:05 2003
From: taj at linuxgrrls.org (Trent Jarvi)
Date: Sun, 9 Nov 2003 17:07:05 +0000 (GMT)
Subject: [Rxtx] filtered email comming
Message-ID: <Pine.LNX.4.58.0311091705180.31385@hex.linuxgrrls.org>


I've been gone for a week and have not had time to look at the filtered 
email.  The next couple of emails are slow getting to the list and it was 
my fault.




From edpersson at yahoo.com  Wed Nov  5 13:20:53 2003
From: edpersson at yahoo.com (Erik Persson)
Date: Wed, 5 Nov 2003 12:20:53 -0800 (PST)
Subject: [Rxtx] rxtx-2.1.6, OS X 10.3 (Panther), "Bus Error"
Message-ID: <20031105202053.18309.qmail@web40907.mail.yahoo.com>

Greetings,

I have downloaded, compiled and installed both
rxtx-2.1-6 and rxtx-2.1-7pre17 under Mac OSX 10.3.

In both cases I used the pbproject with XCode.  The
only change I had to make was the addition of a Mach-O
Linker flag of "-dynamiclib".

After doing some very simple verifications using
contrib/Test.java, I compiled and tried to use the
Dallas Semicondutor iButton software which uses rxtx. 
After a quick change to the imports (gnu.io) and a few
changes for JDK1.4 support, I thought I was ready to
go.

A quick "Bus error" indicated that all was not well. 
After digging around a bit, I have found the
following, perhaps meaningful error information.

If there is an rxtx test suite that I should run or
any other debugging that would help, I am happy to do
so.

It may well be that this bug is in Panther and not
RXTX, but I figured I would start here since I suspect
that Apple developers are a bit busy at the moment! 
;-)  My apologies in advance if this post is
off-topic, does not provide enough detail, should have
waited for me to do more debugging, or is just too
boring for this list.

The java code in question is trying to flush on a
SerialPort's output stream when the kernel exception
occurs.

With DEBUG and DEBUG_VERBOSE defined for the RXTX
jnilibs I get the following output (the first line
coming from the dalsemi java code):

DEBUG: USerialAdapter-flush
W(c1)writeByte ?>>
writeByte:  index->writing = 1RXTXPort:writeByte 1
nativeDrain: trying tcdrain
RXTXPort:drain() returns: 0
send_event: !eventloop_interupted
send_event: jclazz
send_event: calling
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_fionread: change is 0
entering check_tiocmget_changes
leaving check_tiocmget_changes
port_has_changed_